Re: Potential partition pruning regression on PostgreSQL 18
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Cándido Antonio Martínez Descalzo <candido@ninehq.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-02T07:34:33Z
Lists: pgsql-hackers, pgsql-performance
Attachments
- v1-0001-Strip-PlaceHolderVars-from-partition-pruning-oper.patch (application/octet-stream) patch v1-0001
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Strip PlaceHolderVars from partition pruning operands
- 8e8b2bef780e 18.4 landed
- c1408956e393 19 (unreleased) landed