Re: Runtime pruning problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Runtime pruning problem
Date
Msg-id 2923.1555474214@sss.pgh.pa.us
Whole thread Raw
In response to Re: Runtime pruning problem  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Runtime pruning problem
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: log_planner_stats and prepared statements
Next
From: "Ideriha, Takeshi"
Date:
Subject: RE: Copy data to DSA area