| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Cándido Antonio Martínez Descalzo <candido(at)ninehq(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Potential partition pruning regression on PostgreSQL 18 |
| Date: | 2026-04-09 08:05:11 |
| Message-ID: | CAMbWs4-gsKrhs9attotkw1eRNC3oFeB8damkO04_iukULWF=5g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On Tue, Apr 7, 2026 at 5:00 PM Richard Guo <guofenglinux(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2026-04-09 08:16:33 | Re: Centralised architecture detection |
| Previous Message | Nazir Bilal Yavuz | 2026-04-09 08:01:55 | Re: Upload only the failed tests logs to the Postgres CI (Cirrus CI) |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Jeff Davis | 2026-04-07 21:58:22 | Re: Significant performance issues with array_agg() + HashAggregate plans on Postgres 17 |