From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, 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 |
Date: | 2019-07-30 22:32:35 |
Message-ID: | CAKJS1f8NDUNRY=YEMj1-qkyGvJi4AOL7v7LsGNx1spZQf-P7mA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 31 Jul 2019 at 10:27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <david(dot)rowley(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Migowski | 2019-07-30 22:32:46 | Re: Adding column "mem_usage" to view pg_prepared_statements |
Previous Message | Tom Lane | 2019-07-30 22:29:53 | Re: AW: AW: Adding column "mem_usage" to view pg_prepared_statements |