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-09T08:05:11Z
Lists: pgsql-hackers, pgsql-performance
On Tue, Apr 7, 2026 at 5:00 PM Richard Guo <guofenglinux@gmail.com> wrote: > 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? I prefer to be cautious, so I've committed the patches as-is. - 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