Feedback-ID: ia2694551:Fastmail
Date: Thu, 1 Dec 2022 12:21:06 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Jacob Champion <jchampion@timescale.com>,
	Zhihong Yu <zyu@yugabyte.com>, David Rowley <dgrowleyml@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: generic plans and "initial" pruning
Message-ID: <20221201112106.gjlcv6nvndjbnoez@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+HiwqG=yLd843jneu09fG+hFTQWYYw1xtxchh0hA5N+gofJhg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20221201112106.gjlcv6nvndjbnoez%40alvherre.pgsql>
Precedence: bulk

On 2022-Dec-01, Amit Langote wrote:

> Hmm, how about keeping the [Merge]Append's parent relation's RT index
> in the PartitionPruneInfo and passing it down to
> ExecInitPartitionPruning() from ExecInit[Merge]Append() for
> cross-checking?  Both Append and MergeAppend already have a
> 'apprelids' field that we can save a copy of in the
> PartitionPruneInfo.  Tried that in the attached delta patch.

Ah yeah, that sounds about what I was thinking.  I've merged that in and
pushed to github, which had a strange pg_upgrade failure on Windows
mentioning log files that were not captured by the CI tooling.  So I
pushed another one trying to grab those files, in case it wasn't an
one-off failure.  It's running now:
  https://cirrus-ci.com/task/5857239638999040

If all goes well with this run, I'll get this 0001 pushed.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Investigación es lo que hago cuando no sé lo que estoy haciendo"
(Wernher von Braun)