Re: Runtime pruning problem
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>,
Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-17T04:10:14Z
Lists: pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes: > On Wed, 17 Apr 2019 at 15:54, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> What I'm more worried about is whether this breaks any internal behavior >> of explain.c, as the comment David quoted upthread seems to think. >> If we need to have a tlist to reference, can we make that code look >> to the pre-pruning plan tree, rather than the planstate tree? > I think most of the complexity is in what to do in > set_deparse_planstate() given that there might be no outer plan to > choose from for Append and MergeAppend. This controls what's done in > resolve_special_varno() as this descends the plan tree down the outer > side until it gets to the node that the outer var came from. > We wouldn't need to do this if we just didn't show the targetlist in > EXPLAIN VERBOSE, but there's also MergeAppend sort keys to worry about > too. Should we just skip on those as well? No, the larger issue is that *any* plan node above the Append might be recursing down to/through the Append to find out what to print for a Var reference. We have to be able to support that. regards, tom lane
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