Cool stuff!
On 25/05/18 06:35, Andres Freund wrote:
> For example, this converts this converts TPCH's Q01:
>
> tpch_1[26142][1]=# SET client_min_messages ='log';
> tpch_1[26142][1]=# SELECT
> l_returnflag,
> l_linestatus,
> sum(l_quantity) AS sum_qty,
> sum(l_extendedprice) AS sum_base_price,
> sum(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
> sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
> avg(l_quantity) AS avg_qty,
> avg(l_extendedprice) AS avg_price,
> avg(l_discount) AS avg_disc,
> count(*) AS count_order
> FROM
> lineitem
> WHERE
> l_shipdate <= date '1998-12-01' - interval '74 days'
> GROUP BY
> l_returnflag,
> l_linestatus
> ORDER BY
> l_returnflag,
> l_linestatus;
> LOG: 00000: pp:
>
> into:
>
> 0: init_sort
> 1: seqscan_first
> 2: seqscan [j empty 5] > s0
> 3: qual [j fail 2] < scan s0
> 4: hashagg_tuple [j 2] < s0
> 5: drain_hashagg [j empty 7] > s1
> 6: sort_tuple [j 5] < s1
> 7: sort
> 8: drain_sort [j empty 10] > s2
> 9: return < s2 [next 8]
> 10: done
>
> where s are numbered slots, j are, potentially conditional, jumps. This
> works for a number of plans, but there's several where we currently bail
> out.
How is this going to look like in EXPLAIN, even without ANALYZE? Would
it still show a tree plan, or this linear program, or both?
> Despite being entirely unoptimized this already yields a measurable
> speedup over the current executor for the TPCH queries it supports.
Oh, that's impressive!
- Heikki
