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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: pgsql-hackers(at)postgresql(dot)org, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: Redesigning the executor (async, JIT, memory efficiency)
Date: 2018-05-25 06:40:55
Message-ID: 20180525064055.6oc5gcly33v5z27p@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-05-25 09:26:47 +0300, Heikki Linnakangas wrote:
> Cool stuff!

Thanks!

> 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?

I think we're going to have to continue showing the tree plan. I think
the linear version is far too hard to understand for anything
nontrivial. I'd definitely continue to expect the Plan tree to be tree
shaped, and I'm currently not forseeing to entirely get rid of PlanState
trees (albeit with smaller nodes, and potentially with relative rather
than absolute pointers to children). So I don't really forsee a huge
problem continuing to display a tree shaped plan.

I'd expect there'd be an EXPLAIN option to show the linear plan, but
that that'd not be used frequently outside of development work.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Arseny Sher 2018-05-25 06:43:23 Re: Possible bug in logical replication.
Previous Message Heikki Linnakangas 2018-05-25 06:40:10 Re: Keeping temporary tables in shared buffers