Re: Runtime pruning problem

David Rowley <david.rowley@2ndquadrant.com>

From: David Rowley <david.rowley@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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-07-30T22:32:35Z
Lists: pgsql-hackers
On Wed, 31 Jul 2019 at 10:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <david.rowley@2ndquadrant.com> writes:
> > The part I wouldn't mind another set of eyes on is the ruleutils.c
> > changes.
>
> Um, sorry for not getting to this sooner.
>
> What I had in mind was to revert 1cc29fe7c's ruleutils changes
> entirely, so that ruleutils deals only in Plans not PlanStates.
> Perhaps we've grown some code since then that really needs the
> PlanStates, but what is that, and could we do it some other way?
> I'm not thrilled with passing both of these around, especially
> if the PlanState sometimes isn't there, meaning that no code in
> ruleutils could safely assume it's there anyway.

Are you not worried about the confusion that run-time pruning might
cause if we always show the Vars from the first Append/MergeAppend
plan node, even though the corresponding executor node might have been
pruned?

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



Commits

  1. Put back regression test case in a more robust form.

  2. Allow executor startup pruning to prune all child nodes.

  3. Further adjust EXPLAIN's choices of table alias names.