From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <david.rowley@2ndquadrant.com>
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>
Subject: Re: Runtime pruning problem
In-reply-to: 
 <CAKJS1f8NDUNRY=YEMj1-qkyGvJi4AOL7v7LsGNx1spZQf-P7mA@mail.gmail.com>
References: <001001d4f44b$2a2cca50$7e865ef0$@lab.ntt.co.jp>
 <CAKJS1f_4b9J7K7DSuZMkyga67OetfyAWz1xzYJd25HSf9-cijQ@mail.gmail.com>
 <b50238ec-e402-6fcb-7f3a-b74418471b29@lab.ntt.co.jp>
 <CAKJS1f98o-6-SWWzcfiJO6JAQFu2DnYWBzFVB0x2+u5ub=ASEA@mail.gmail.com>
 <c4acce90-8265-c91f-065f-e4507ad054bd@lab.ntt.co.jp>
 <2018.1555473241@sss.pgh.pa.us>
 <CAKJS1f9ch8rVy8ZhsV2J7q0zCq4xFuXWxTT90EadpkTsgCvQQw@mail.gmail.com>
 <2923.1555474214@sss.pgh.pa.us>
 <f1ad1911-df47-b555-8df5-825e3a8aa69c@lab.ntt.co.jp>
 <17368.1555608352@sss.pgh.pa.us>
 <CAKJS1f_020O9bX-c1cGcDM2L5DU44hRQ3k_0MXBBqKxAQ=X5bg@mail.gmail.com>
 <CAKJS1f_GZ6LtonDHBJ0pgwtT+OFWmJBap60Fb9iQ++it4aXCFA@mail.gmail.com>
 <CAKJS1f_mw47rnotO4VvpmH42cVKAPn0bkTCzevugGPqeQrW6uQ@mail.gmail.com>
 <CAKJS1f82v4fEtH-XkGfUq-QEDErYBvkH8BkmchAT53vUjD+g7Q@mail.gmail.com>
 <6779.1564525639@sss.pgh.pa.us>
 <CAKJS1f8NDUNRY=YEMj1-qkyGvJi4AOL7v7LsGNx1spZQf-P7mA@mail.gmail.com>
Comments: In-reply-to David Rowley <david.rowley@2ndquadrant.com>
	message dated "Wed, 31 Jul 2019 10:32:35 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7813.1564527032.1@sss.pgh.pa.us>
Date: Tue, 30 Jul 2019 18:50:32 -0400
Message-ID: <7814.1564527032@sss.pgh.pa.us>
Precedence: bulk

David Rowley <david.rowley@2ndquadrant.com> writes:
> On Wed, 31 Jul 2019 at 10:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?

The upper-level Vars should ideally be labeled with the append parent
rel's name anyway, no?  I think it's likely *more* confusing if those
Vars change appearance depending on which partitions get pruned or not.

This may be arguing for a change in ruleutils' existing behavior,
not sure.  But when dealing with traditional-style inheritance,
I've always thought that Vars above the Append were referring to
the parent rel in its capacity as the parent, not in its capacity
as the first child.  With new-style partitioning drawing a clear
distinction between the parent and all its children, it's easier
to understand the difference.

			regards, tom lane