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 pageSeqPushHeapTuple(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 destreturn SendReadyTuple(slot, pusher);}
对于hash join来说,需要先构建hash表,然后外表数据从hash表中进行探测;pipeline引擎中怎么推送完成hash join呢?
从RunNode函数中可以也可以看到,他是先从内表分支开始推送数据,推送给Hash节点构建hash表,然后推送给父节点。pushTuple函数中,当hash join的右分支推送上来时,pushTupleToHashJoinFromInner函数仅获取hash表,并不继续向上推送;而是HashJoin的左子分支推送上来的数据进入pushTupleToHashJoinFromOuter,进行hash探测,找到符合条件的数据,并向上层父节点推送join结果:
可以得知,该改造并没有充分利用各个叶子分支并行,未来可以向整个方向进行优化。
3、效果
TPCH的 q1, q3, q4, q5,q10, q12 and q14:
4、总结
1)红色线:找叶子节点递归方向;蓝色线:数据推送方向
2)物理执行计划被执行器ExecInitNode初始化时,参数带入父节点,从而将执行计划构建为子节点-->父节点的关系
3)通过RunNode递归调用,找到叶子节点SeqScan。获取数据后推送给父节点Hash
4)Hash节点构建hash表,推送给父节点HashJoin。因为数据处于HashJoin的右分支,所以通过pushTupleToHashJoinFromInner仅获取hash表,到此该分支推送执行就结束了
5)左分支SeqScan获取数据后推送给HashTable,HashJoin由pushTupleToHashJoinFromOuter执行,进行hash探测并将join的结果推送给上层父节点,若无上层父节点,则推送给用户,至此push-based pipeline执行结束。
6)该改造,并没有将pipeline依据叶子节点进行并行执行,仍旧有提升空间;当然,仅作为一个初次尝试,验证push-based pipeline执行。和clickhouse、starrocks等相比,仍旧有很大不足。
5、参考
https://postgrespro.com/list/thread-id/2309959
https://wiki.postgresql.org/wiki/GSoC_2017#Implementing_push-based_query_executor