cmu 15445 p3

火山模型

可以看出火山模型的优点在于：简单，每个 Operator 可以单独抽象实现、不需要关心其他 Operator 的逻辑。

那么缺点呢？也够明显吧？每次都是计算一个 tuple（Tuple-at-a-time），这样会造成多次调用 next ，也就是造成大量的虚函数调用，这样会造成 CPU 的利用率不高。

整体架构：

Query 1中考察如何将seq scan+filter转换为index scan，按照官方给出的优化建议得到的设计是将index iterator定位到第一个满足predicate的index tuple然后向后遍历找出其余所有满足predicate的index tuples。观察select语句发现，x和y均为int，x需满足大于等于，y需满足相等，x为索引第一列，y为索引第二列。那么每次我们将index iterator定位到满足predicate的index tuple后，将此index tuple的x值++后重新定位index iterator（如果未找到满足条件的index tuple则执行++index iterator），重复此过程找到下一个满足predicate的index tuple，便可跳过所有不满足y相等条件的index tuple。

 SELECT * FROM t1 WHERE x >= 90 AND y = 10    

query 2 实际上是nlj 转换 为hash ，并实现谓词下推

CREATE TABLE t4(x int, y int);
CREATE TABLE t5(x int, y int);
CREATE TABLE t6(x int, y int);
EXPLAIN SELECT * FROM t4, t5, t6
  WHERE (t4.x = t5.x) AND (t5.y = t6.y) AND (t4.y >= 1000000)
    AND (t4.y < 1500000) AND (t6.x >= 100000) AND (t6.x < 150000)

示意图如下图所示 

q3

CREATE TABLE t7(v INT, v1 INT, v2 INT);
CREATE TABLE t8(v INT, v1 INT, v2 INT, v3 INT, v4 INT);
insert into t7 values (1,2,3), (1,3,4);
explain SELECT v, d1, d2 FROM (
  SELECT v,
         MAX(v1) AS d1, MIN(v1), MAX(v2), MIN(v2),
         MAX(v1) + MIN(v1), MAX(v2) + MIN(v2),
         MAX(v1) + MAX(v1) + MAX(v2) AS d2
    FROM t7 LEFT JOIN (SELECT v4 FROM t8 WHERE 1 == 2) ON v < v4
    GROUP BY v
);

这里的实现参考这篇博客

增加了常量判断 1==2 直接predicate为false ，同时进行列的修建，实际涉及到的列仅为v1,v2,v

总而言之优化真的是门技术活，而且这里有点相当于面向测试用例优化，仅考虑了提供的测试样例的情况。