pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
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>
Cc: Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Runtime pruning problem
Date: Tue, 30 Jul 2019 18:50:32 -0400
Message-ID: <7814.1564527032@sss.pgh.pa.us> (raw)
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>

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





view thread (38+ messages)  latest in thread

Message-ID: <7814.1564527032@sss.pgh.pa.us>
Permalink:  ../7814.1564527032@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/7814.1564527032@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, david.rowley@2ndquadrant.com, Langote_Amit_f8@lab.ntt.co.jp, hosoya.yuzuko@lab.ntt.co.jp, pgsql-hackers@lists.postgresql.org
  Subject: Re: Runtime pruning problem
  In-Reply-To: <7814.1564527032@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox