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
-
Put back regression test case in a more robust form.
- 22864f6e02f8 13.0 landed
-
Allow executor startup pruning to prune all child nodes.
- 5935917ce59e 13.0 landed
-
Further adjust EXPLAIN's choices of table alias names.
- 6ef77cf46e81 13.0 landed