Re: Runtime pruning problem

On Wed, 17 Apr 2019 at 15:54, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> > On 2019/04/17 11:29, David Rowley wrote:
> >> Where do you think the output list for EXPLAIN VERBOSE should put the
> >> output column list in this case? On the Append node, or just not show
> >> them?
>
> > Maybe, not show them?
>
> Yeah, I think that seems like a reasonable idea. If we show the tlist
> for Append in this case, when we never do otherwise, that will be
> confusing, and it could easily break plan-reading apps like depesz.com.
>
> 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?

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services