Re: Runtime pruning problem
От | Tom Lane |
---|---|
Тема | Re: Runtime pruning problem |
Дата | |
Msg-id | 2923.1555474214@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Runtime pruning problem (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: Runtime pruning problem
|
Список | 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
В списке pgsql-hackers по дате отправления: