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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Redesigning the executor (async, JIT, memory efficiency)
Дата
Msg-id 20180525064055.6oc5gcly33v5z27p@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Redesigning the executor (async, JIT, memory efficiency)  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Redesigning the executor (async, JIT, memory efficiency)  (Robert Haas <robertmhaas@gmail.com>)
Re: Redesigning the executor (async, JIT, memory efficiency)  (Douglas Doole <dougdoole@gmail.com>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Keeping temporary tables in shared buffers
Следующее
От: Arseny Sher
Дата:
Сообщение: Re: Possible bug in logical replication.