Re: Runtime pruning problem

Amit Langote <langote_amit_f8@lab.ntt.co.jp>

From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-19T08:13:43Z
Lists: pgsql-hackers

Attachments

On 2019/04/19 17:00, Amit Langote wrote:
> 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.

The patch I attached with the previous email didn't update the expected
output file.  Correct one attached.

Thanks,
Amit

Commits

  1. Put back regression test case in a more robust form.

  2. Allow executor startup pruning to prune all child nodes.

  3. Further adjust EXPLAIN's choices of table alias names.