过一个案例介绍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没有联系？