PgSQL内核特性 - push-based pipeline 执行引擎

数据库的SQL执行引擎负责处理和执行SQL请求。通常情况下，查询优化器会输出物理执行计划，一般由一系列的算子组成。当前，有两种算子流水线构建方式：1）需求驱动的流水线，由算子不断从下级算子拉取数据；2）数据驱动的流水线，由算子将每个数据推送给父算子。

论文《Push versus pull-based loop fusion in query engines》说明了push和pull执行引擎的区别：

Pull流水线基于经典的火山迭代器模型，将每个操作抽象成一个算子。整个SQL语句构成一个算子树，从树顶递归调用next接口，向下层算子请求数据，直到查询计划树的叶子节点。优缺点：

1）以行为单位处理数据，每一行数据的处理都会调用next接口（当然也可以基于pull模型改造成以batch为单位处理数据）

2）以行为单位处理，会导致CPU缓存使用效率低下

3）火山模型接口看起来干净且易懂

论文《Efficiently compiling efficient query plans for modern hardware》提出的Push模型采用Pipeline来组合算子，自底而上Push调度。Pipeline的目的：1）降低计算节点的任务调度代价；2）提升 CPU 利用率；3）充分利用多核计算能力，提升查询性能、自动设置并行度、消除人为设置并行度的不准确性。

1、PgSQL的pipeline执行引擎

GSoC 2017中有个改造pipeline的项目，基本思想是遍历执行计划树，找到叶子节点，从叶子节点开始获取数据，然后推送给各个父节点。

执行器中，使用RunNode函数递归调用，得到叶子节点：先遍历右节点，然后再遍历左节点；当然若没有右节点，则直接遍历左节点；当没有左右子节点时，就到了叶子节点，那么通过pushTuple来推送数据。

pushTuple根据父节点类型调用各自推送函数，将数据推送给父节点，比如上面流程：当父节点是LimitState时，调用pushTupleToLimit进行推送。

我们看下SeqScan：其实就是从存储引擎获取数据，进行过滤和投影，然后根据父节点类型，推送给父节点。

pushTupleToSeqScan(SeqScanState *node)
  heappushtups(...,node->ss.ps.parent,node)
    |--  get a tuple in the page
      SeqPushHeapTuple(HeapTuple tuple, PlanState *node,SeqScanState *pusher)
      |--  slot = SeqStoreTuple(pusher, tuple);
      |--  ExecQual && ExecProject
      |--  return pushTuple(slot, node, (PlanState *) pusher);
        |--  if (!node){//pusher top level node, send to dest
            return SendReadyTuple(slot, pusher);
          }

对于hash join来说，需要先构建hash表，然后外表数据从hash表中进行探测；pipeline引擎中怎么推送完成hash join呢？

从RunNode函数中可以也可以看到，他是先从内表分支开始推送数据，推送给Hash节点构建hash表，然后推送给父节点。pushTuple函数中，当hash join的右分支推送上来时，pushTupleToHashJoinFromInner函数仅获取hash表，并不继续向上推送；而是HashJoin的左子分支推送上来的数据进入pushTupleToHashJoinFromOuter，进行hash探测，找到符合条件的数据，并向上层父节点推送join结果：