Re: Runtime pruning problem

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Yuzuko Hosoya <hosoya(dot)yuzuko(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Runtime pruning problem
Date: 2019-04-19 08:00:57
Message-ID: 28ae1b0e-a33a-b785-6bad-1814b0324c4e@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019/04/19 2:25, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
>> Another idea is to teach explain.c about this special case of run-time
>> pruning having pruned all child subplans even though appendplans contains
>> one element to cater for targetlist accesses. That is, Append will be
>> displayed with "Subplans Removed: All" and no child subplans listed below
>> it, even though appendplans[] has one. David already said he didn't do in
>> the first place to avoid PartitionPruneInfo details creeping into other
>> modules, but maybe there's no other way?
>
> I tried simply removing the hack in nodeAppend.c (per quick-hack patch
> below), and it gets through the core regression tests without a crash,
> and with output diffs that seem fine to me. However, that just shows that
> we lack enough test coverage; we evidently have no regression cases where
> an upper node needs to print Vars that are coming from a fully-pruned
> Append. Given the test case mentioned in this thread, I get
>
> regression=# explain verbose select * from t1 where dt = current_date + 400;
> QUERY PLAN
> ---------------------------------------------
> Append (cost=0.00..198.42 rows=44 width=8)
> Subplans Removed: 4
> (2 rows)
>
> which seems fine, but
>
> regression=# explain verbose select * from t1 where dt = current_date + 400 order by id;
> psql: server closed the connection unexpectedly
>
> It's dying trying to resolve Vars in the Sort node, of course.

Another approach, as I mentioned above, is to extend the hack that begins
in nodeAppend.c (and nodeMergeAppend.c) into explain.c, as in the
attached. Then:

explain verbose select * from t1 where dt = current_date + 400 order by id;
QUERY PLAN
───────────────────────────────────────────────────
Sort (cost=199.62..199.73 rows=44 width=8)
Output: t1_1.id, t1_1.dt
Sort Key: t1_1.id
-> Append (cost=0.00..198.42 rows=44 width=8)
Subplans Removed: 4
(5 rows)

It's pretty confusing to see t1_1 which has been pruned away, but you
didn't seem very interested in the idea of teaching explain.c to use the
original target list of plans like Append, MergeAppend, etc. that have
child subplans.

Just a note: runtime pruning for MergeAppend is new in PG 12.

Thanks,
Amit

Attachment Content-Type Size
explain-fully-pruned-append-mergeappend.patch text/plain 2.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-04-19 08:03:07 Re: Runtime pruning problem
Previous Message Michael Paquier 2019-04-19 08:00:26 Re: clean up docs for v12