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
- explain-fully-pruned-append-mergeappend-2.patch (text/plain) patch
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
-
Put back regression test case in a more robust form.
- 22864f6e02f8 13.0 landed
-
Allow executor startup pruning to prune all child nodes.
- 5935917ce59e 13.0 landed
-
Further adjust EXPLAIN's choices of table alias names.
- 6ef77cf46e81 13.0 landed