说实话，本人在没看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。