过一个案例介绍PG执行计划相关数据结构:PlanState和Plan。
以下面执行计划为例:
postgres=# explain select *from t2 where id1>(select t1.id1 from t1,t2 where t1.id1=t2.id1)-------------------------------------QUERY PLAN--------------------------------------------Seq Scan on t2 (cost = 69.73..87.23 rows=333 width=8) Filter :(id1>$0) InitPlan 1 (return $0) -> Hash Join (cost=27.50..69.73 rows=2550 width=4) Hash Cond:(t1.id1=t2_1.id1) ->Seq Scan On t1 (cost=0.00.35.50 rows=2550 width=4) ->Hash (cost=15.00..15.00 rows=1000 width=4) ->Seq Scan On t2 t2_1 (cost=0.00..15.00 rows==1000 width=4)(8 rows)postgres=#
其中,相关子查询概念是内部依赖于外部,外部每次执行一次内部都执行一次,都是外部先执行,然后内部再执行,子查询需要外部传入值。而非相关子查询是内部查询独立于外部查询,仅需要执行一次并将结果作为外部查询条件使用。数据结构Plan中initPlan成员即为非相关子查询的链表指针。从上面的例子中可以知道子查询仅执行一次且独立于外部查询,所以他的执行计划中有InitPlan节点。其关系参考下图。
Plan结构的targetlist为该节点需要计算的目标列表。qual为查询条件(没有用到索引的),lefttree和righttree分别为左子树和右子树,即本利中的Seq Scan节点和Hash节点。
plan_node_id为该节点在本执行计划树种的唯一标识,从0开始。根节点为0。
而子查询通过Plan中initPlan进行管理,对于数据结构为SubPlanState进行描述。该结构中有planstate指向子查询节点,本例子中为HashJoin节点的状态描述结构。而parent则指向父节点的状态结构,本例中为SeqScanState。
子查询计划SubPlan和子计划HashJoin没有联系?
参与评论
登录后参与讨论 0/1000