PostgreSQL执行器性能（一）

以下是我在阅读执行器说明的一些内容，我想这对于阅读执行器的源代码还是有所帮助的。如果有什么写的不对的，请大家提出来帮忙修改一下。（主要来源于源代码说明）

执行器处理的是一棵“规划节点”树。该规划树本质上是一个需求拉动的元组处理操作流水线。每个节点被调用时将会在它的输出队列产生下一个元组，如果没有下一个可用的节点则返回空值。如果该节点不是原始的关系扫描节点，那么它将会有子节点，这些子节点将会被顺序掉用来获得输入元组。

相对于最原始的模型，现在的PostgreSQL的改进之处：

选择扫描方向（向前或向后）。注意：这现在并没有得到很好的支持。它适用于原始节点扫描，但是对于连接、聚类等方面的处理不是很好。（我想这也是PostgreSQL执行器所存在的比较大的一个缺点，但是想要改善这一缺点难度还是很大的）

重新扫描：命令重置节点并使其重新生成输出序列。

参数：可以改变一个节点的结果。在调整一个参数之后，对应于它的扫描命令必须适应于该节点以及该节点前面的节点。这里有一个适度的智能规划来避免不必要的节点重新扫描。例如，如果它的输入参数没有改变，排序将不会重新扫描它的输入，因为他可以读取它已经存在的排序信息。

规划树原理直接实现“select”：它仅需要向客户传递最顶层的结果，或者在“insert…select”的情况下它的结果插入到另一个表中。（“insert…value”的处理情况相似，但是它的规划树仅是一个没有资源表的结果节点。）对于“update”，规划树选择选择需要被更新的元组（where条件），并为给每个元组传递一个新计算出来的元组值，加入一个隐形的“junk”元组CTID用于识别目标元组。然后执行器的最上层用这个信息来更新符合条件的元组。“delete”与“update”相似，除了进需要传递给规划树一个CTID。

姓名：吴冰 主题：执行器

转载于:https://www.cnblogs.com/tjdx415/archive/2010/01/19/1651784.html