Re: Redesigning the executor (async, JIT, memory efficiency)

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