Re: Potential partition pruning regression on PostgreSQL 18 - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Potential partition pruning regression on PostgreSQL 18
Date
Msg-id CAMbWs48w9424moGiS_f5jPhL3fMLRn+Q1FTLOzDsRZy-DvuUFA@mail.gmail.com
Whole thread Raw
In response to Re: Potential partition pruning regression on PostgreSQL 18  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-hackers
On Thu, Apr 2, 2026 at 4:34 PM Richard Guo <guofenglinux@gmail.com> wrote:
> Attached is a draft patch for the fix.
>
> Regarding backpatching, I'm inclined to only back-patch this down to
> v18.  This issue actually predates v18, for example, when the
> partition key is a non-Var expression.  A non-Var target item will be
> wrapped in a PHV, causing us to fail the partition key match.
> However, the changes in v18 seem to have made the issue common enough
> to notice.  This is very similar to the index matching case.

Here are the more formal patches for HEAD and for v18.

In the HEAD patch, I renamed strip_phvs_in_index_operand() to
strip_noop_phvs() and moved it from indxpath.c to placeholder.c, since
it is now a general-purpose utility used by both index matching and
partition pruning code.

However, since strip_phvs_in_index_operand() is an extern function
declared in a public header, I'm worried that third-party extensions
may have started calling it after it was introduced in ad66f705f.  So
for the v18 back-patch, I retained strip_phvs_in_index_operand() in
indxpath.c as a thin wrapper around the new strip_noop_phvs(), to
avoid breaking such extensions in a minor release.

Does this seem like reasonable caution, or is it overkill given how
recently the function was introduced?

- Richard

Attachment

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Query Regarding Blog Submission Approval on Planet PostgreSQL
Next
From: Lukas Fittl
Date:
Subject: Re: EXPLAIN: showing ReadStream / prefetch stats