|From:||Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Yuzuko Hosoya <hosoya(dot)yuzuko(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Runtime pruning problem|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2019/04/17 12:58, David Rowley wrote:
> 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
>>> 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?
I guess so, if only to be consistent with Append.
|Next Message||Tom Lane||2019-04-17 04:04:35||Re: log_planner_stats and prepared statements|
|Previous Message||David Rowley||2019-04-17 03:58:52||Re: Runtime pruning problem|