ppg_fdw:如何使用pgsql构建mpp数据仓库(五)

     子查询的处理
   说实话,本人在没看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。

你可能感兴趣的:(数据仓库)