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 CAMbWs49ittTvqB50_=eNPwN3-HAJX__s3kfn5nJc3nABTUZoyQ@mail.gmail.com
Whole thread Raw
Responses Re: Potential partition pruning regression on PostgreSQL 18
List pgsql-hackers
On Thu, Apr 2, 2026 at 8:01 AM David Rowley <dgrowleyml@gmail.com> wrote:
> The question is, can we do the same thing in
> match_clause_to_partition_key() as we did for index clauses in
> ad66f705f. The PlaceHolderVar's phnullingrels are empty for this
> query, so I expect we just need to give the same treatment to
> partition key columns as was done for indexes columns in
> fix_indexqual_operand().

Agreed.  The clauses in match_clause_to_partition_key() are always
relation-scan-level expressions, where a PHV with an empty
phnullingrels is effectively a no-op.  Therefore, we can safely strip
such PHVs.

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.

- Richard

Attachment

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: pg_test_timing: fix unit typo and widen diff type
Next
From: Chao Li
Date:
Subject: Re: PoC: Add condition variable support to WaitEventSetWait()