子查询的处理
说实话，本人在没看PG之前，一直看mysql的文档里面讲子查询，什么From、drived子查询啥的，一直晕乎乎的。但是在看了PG代码之后，终于感觉略微明白了点。
具体说来，SQL里面，出现在rtable里面的子查询才可以称为是subquery，而出现在过滤条件（例如expression）中的被称为sublink。
例如：
select count(t1.a), tt.b from t1, (select t2.b, t2.c from t2) as tt where t1.a in (select d from t3) and t1.a = tt.c group by tt.b having count(t1.a) < (select max(t3.a) from t3)
很明显，select t2.b from t2是subquery，而select c from t3 select max(t3.a) from t3都是sublink。
对于这个实例，PG会先将jointree中含有的sublink转成左半连接的subquery，生成一个新的jointree（见pull_up_sublink），然后将jointree中简单的subquery提上来（pull_up_subqueries）如是上面的SQL会被改写成如下的SQL:
select count(t1.a), t2.b from (t1, t2,) semi joi t3 on ( t1.a = t3.d )) where t1.a = t2.c group by t2.b having count(t1.a) < (select max(t3.a) from t3)
注意 semi join实际上是数据库内部的概念，不是一个标准token。被pullup的sublink一般都是简单的SQL， 而且是exist in 或是any条件中的，具体见代码。而对于在jointree中的不能pullup的sublink以及having语句中sublink，实际上是在pull_up_sublink和pull_up_subqueries之后处理的（见preprocess_expression）。这些sublink，分为两种，一种是的独立sublink，这类sublink的SQL中不引用上层的Query中的变量（var）；另外一种就是相关的sublink，引用了上层的var。
对于独立的sublink， 查询优化器会为之生成initplan，initplan只会被执行一次，但是存储了结果，having 条件通过变量编号来引用这个initplan。
如果是关联的sublink，查询优化器会为之生成subplan。外围的having对应的expression在执行时（实际就是一个agg的filter），会传入所引用的var的实际值，然后执行这个subplan，来获得expression的结果。
好了，在研究了单机的PG如何处理子查询之后，下面我们将描述ppg_fdw如何处理子查询的SQL.
首先，对于出现在jointree中的sublink，ppg_planner直接调用PG的接口（pull_up_sublink,pull_up_subqueries）来改写Query，最终变成不存在子查询的SQL。例如，对于这条SQL实例：
select o_orderpriority, count(*) as order_count from orders where o_orderdate >= date '1993-07-01' and o_orderdate < date '1993-07-01' + interval '3' month and exists ( select * from lineitem where l_orderkey = o_orderkey and l_commitdate < l_receiptdate ) group by o_orderpriority order by o_orderpriority LIMIT 1;
ppg_planner会将sublink消灭之后只剩下semi join，然后采用和前面处理join和agg的方式生成全局最优plan以及下推的子计划（略去）。
而对于下面的SQL，实际上就需要initplan了：
select ps_partkey, sum(ps_supplycost * ps_availqty) as value from partsupp, supplier, nation where ps_suppkey = s_suppkey and s_nationkey = n_nationkey and n_name = 'PERU' group by ps_partkey having sum(ps_supplycost * ps_availqty) > ( select sum(ps_supplycost * ps_availqty) * 0.0001000000 from partsupp, supplier, nation where ps_suppkey = s_suppkey and s_nationkey = n_nationkey and n_name = 'PERU' ) order by value desc LIMIT 1;
因为
select sum(ps_supplycost * ps_availqty) * 0.0001000000 from partsupp, supplier, nation where ps_suppkey = s_suppkey and s_nationkey = n_nationkey and n_name = 'PERU'是一个独立的SQL，因此ppg_planner会为之生成一个plan，然后将这个plan的编号塞入上层的havingClause的expression中被引用。
而对于下面这个例子，则彻底需要subplan：
select s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment from part, supplier, partsupp, nation, region where p_partkey = ps_partkey and s_suppkey = ps_suppkey and p_size = 41 and p_type like '%TIN' and s_nationkey = n_nationkey and n_regionkey = r_regionkey and r_name = 'AFRICA' and ps_supplycost = ( select min(ps_supplycost) from partsupp, supplier, nation, region where p_partkey = ps_partkey and s_suppkey = ps_suppkey and s_nationkey = n_nationkey and n_regionkey = r_regionkey and r_name = 'AFRICA' ) order by s_acctbal desc, n_name, s_name, p_partkey LIMIT 100;
主要是havingcluase的子查询是一个相关的子查询，引用了part表的p_partkey字段。
对于出现在fromclause中的subquery， ppg_planner会尽力在pull_subqueries中消灭之，一般无法pullup的subquery含有agg。如果存在这样的pullup的subquery，那么就要通过ppg_planner来生成子plan。
例如对于这个SQL实例：
select supp_nation, cust_nation, l_year, sum(volume) as revenue from ( select n1.n_name as supp_nation, n2.n_name as cust_nation, extract(year from l_shipdate) as l_year, l_extendedprice * (1 - l_discount) as volume from supplier, lineitem, orders, customer, nation n1, nation n2 where s_suppkey = l_suppkey and o_orderkey = l_orderkey and c_custkey = o_custkey and s_nationkey = n1.n_nationkey and c_nationkey = n2.n_nationkey and ( (n1.n_name = 'KENYA' and n2.n_name = 'VIETNAM') or (n1.n_name = 'VIETNAM' and n2.n_name = 'KENYA') ) and l_shipdate between date '1995-01-01' and date '1996-12-31' ) as shipping group by supp_nation, cust_nation, l_year order by supp_nation, cust_nation, l_year LIMIT 1;
实际上可以将fromclause里面那个子查询pullup，最终变成一个没有子查询的SQL，然后生成全局plan。可以这样处理的TPCH的SQL实例实际上还有若干个，这里就不列举了。
而对于下面这个SQL，则需要处理子查询了。
select c_count, count(*) as custdist from ( select c_custkey, count(o_orderkey) from customer left outer join orders on c_custkey = o_custkey and o_comment not like '%pending%accounts%' group by c_custkey ) as c_orders (c_custkey, c_count) group by c_count order by custdist desc, c_count desc LIMIT 1;ppg_planner会为这条SQL中的子查询首先生成一个plan（为了方便，我们称为子plan），然后为上层的SQL生成一个plan（我们称为父plan）。逻辑上全局plan可以如下表示：
-------------------------
- （limit) - 父plan
- | -
- （sort） -
- | -
- （agg） -
- | -
- (foreign_scan) -
- | -
--------------------------
|
--------------------------
- （agg） -
- | -
- (foreign_scan) - 子plan
--------------------------
（由于这个iteye实在垃圾，上传图片老失败，只能这样讲究了）
父plan的叶子节点是foreign_scan，而这个foreign_scan的输入参数包括要下推的SQL以及子plan的id。
这个plan执行时，会分为两步：一，在executor执行父plan到foreign_scan时，会根据参数，先执行一个建立临时表的语句，然后执行子plan，从子plan获得结果插入临时表；二，一旦完成临时表数据的插入之后，执行父plan，从foreign_scan到二次聚集agg到sort最后到limit。
对于这种子查询处理，需要根据到子查询生成数据量来决定数据的分布方式：如果子查询的数据量小，可以认为是新生成了一个dimension表，并且这时的rangetable就是这个子查询，就像上面的例子，那么可以考虑将子查询的结果在DQP的本地进行处理，那么需要在上图父plan的foreign_scan上面插入一个subquery，省去了在OP上建立临时表和和插入数据的开销；如果子查询的数据量很小，并且还要和rangetable做join，这就要考虑rangetable其他表中是否含有fact表了，如果含有fact表，那么需要将这个新的临时表做全分布了，在每个OP上都建立临时表并都有一个份数据，如果做join的其他全是dimension表，那么这个SQL就演变成了对只含有dimension表的操作了，需要选择一个负载低的OP建立临时表插入数据后，将SQL转发给其处理；如果子查询的数据量比较大，那么认为新产生了一个fact表，需要根据join的字段做重分布，然后下推SQL。具体怎么处理关键需要建立一个统一的模型来估算代价，可能需要向PG的pg_catalog加入一个新的meta表，这个需要进一步研究，To be Done。