PostgreSQL执行机制的初步学习

作为开源数据库的新手，近日有兴对比了Pg和MySQL的查询计划。

通过Pg源码目录下的src\backend\executor\README文件，加上一些简单调试，就能对Pg的执行机制产生一个初步印象；
而MySQL的代码可读性比Pg差了不少，可能还要花些时日去了解先。

原本想写一篇执行机制对比的文章，现在只能谈谈对Pg的体会，不足和错误之处敬请指正。

• Pg算是学院派的开源数据库代表产品，其基于关系代数的优化、操作符的实现看起来十分亲切。相较于MySQL扁平的计划，Pg的执行计划让人一目了然。

• Pg的执行计划静态只读，这是为了重用计划方便。在具体执行某计划时，会有一个包含只读计划指针 + 执行所需信息的State操作符树（对应Plan Trees and State Trees）。类似的表达式也包括Expr和ExprState。

• Pg的执行计划为操作符树，连接如Merge Join，Hash Join为二元操作符，其它为一元操作符。一个特例是相关的semi join过滤，子查询会生成一个SubPlan挂载到过滤条件上，如果过滤条件有n个相关子查询那么就会在scan下方得到n个SubPlan，这一点倒是和Oracle类似（注：12c相关查询处理会更多地进行unnest，在子查询中加了分组才构造出来）。

• 操作符的执行是基于状态的，操作符之间用元组来传递数据。控制权由上而下，数据的传递由下而上。操作符对数据的处理以元组为单位，目前没有批量的优化。

• 操作符中可能涉及表达式计算（接口ExecMakeFunctionResultNoSets），如投影、过滤。根据表达式类型如整型比较、整型相加，会有不同的ExpreState对应。ExprState包含了整型加法或比较用的函数指针，也包含有操作数。 如int_col1 + int_col2，首先加载ExprState的两个操作数：从Tuple中的第n个字段获取值并存放到ExprState的参数中， 接下来使用ExprState的函数指针，结合两个参数进行加法运算并返回结果。

总结：

Pg的执行器代码逻辑很清晰，但是以tuple为单位的处理会使得CPU资源得不到充分利用；
表达式重用优化现在只看到了9.6引入的聚合OP重用；