PostgreSQL执行器性能(一)
以下是我在阅读执行器说明的一些内容,我想这对于阅读执行器的源代码还是有所帮助的。如果有什么写的不对的,请大家提出来帮忙修改一下。(主要来源于源代码说明)
执行器处理的是一棵“规划节点”树。该规划树本质上是一个需求拉动的元组处理操作流水线。每个节点被调用时将会在它的输出队列产生下一个元组,如果没有下一个可用的节点则返回空值。如果该节点不是原始的关系扫描节点,那么它将会有子节点,这些子节点将会被顺序掉用来获得输入元组。
相对于最原始的模型,现在的PostgreSQL的改进之处:
选择扫描方向(向前或向后)。注意:这现在并没有得到很好的支持。它适用于原始节点扫描,但是对于连接、聚类等方面的处理不是很好。(我想这也是PostgreSQL执行器所存在的比较大的一个缺点,但是想要改善这一缺点难度还是很大的)
重新扫描:命令重置节点并使其重新生成输出序列。
参数:可以改变一个节点的结果。在调整一个参数之后,对应于它的扫描命令必须适应于该节点以及该节点前面的节点。这里有一个适度的智能规划来避免不必要的节点重新扫描。例如,如果它的输入参数没有改变,排序将不会重新扫描它的输入,因为他可以读取它已经存在的排序信息。
规划树原理直接实现“select”:它仅需要向客户传递最顶层的结果,或者在“insert…select”的情况下它的结果插入到另一个表中。(“insert…value”的处理情况相似,但是它的规划树仅是一个没有资源表的结果节点。)对于“update”,规划树选择选择需要被更新的元组(where条件),并为给每个元组传递一个新计算出来的元组值,加入一个隐形的“junk”元组CTID用于识别目标元组。然后执行器的最上层用这个信息来更新符合条件的元组。“delete”与“update”相似,除了进需要传递给规划树一个CTID。
姓名:吴冰 主题:执行器