Re: Runtime pruning problem - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Runtime pruning problem
Date
Msg-id 28ae1b0e-a33a-b785-6bad-1814b0324c4e@lab.ntt.co.jp
Whole thread Raw
In response to Re: Runtime pruning problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Runtime pruning problem
Re: Runtime pruning problem
List pgsql-hackers
On 2019/04/19 2:25, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8@lab.ntt.co.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

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: clean up docs for v12
Next
From: Amit Langote
Date:
Subject: Re: Runtime pruning problem