Re: A serious change in performance between PG 15 and PG 16, 17, 18.

David,

I've handed over further communication with you (and others) to Ji Zhang, my (better) technical colleague.
He is able to determine any issues surrounding open/closed publication.

Clive.

Dr Clive Boughton

Software Improvements

Street address:
97 Bankers Road, NSW 2621
Australia

Mobile Phone: +61 (0)410 632 055
Telephone: +61 (0)2 6230 3195

> On 18 Feb 2026, at 11:01 am, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Tue, 17 Feb 2026 at 04:42, Joe Conway <mail(at)joeconway(dot)com> wrote:
>> Are some of your indexes on collatable columns? If so, what version of
>> glibc is on each of your systems (i.e. did you change OS major versions)?
>
> For the record, Clive did send me the query and EXPLAIN output
> offline. I asked him if he'd anonymise it and post it here, but no
> response yet.
>
> I'll just describe what I saw so as not to share details that Clive
> isn't happy making public. The query is to a single table, no joins.
> The filter is equality on an INT column. The v15 plan uses a Seq Scan
> and runs in 175ms. v18 is using a Bitmap Heap Scan using the table's
> primary key index. The PK must be a composite key and the WHERE clause
> must be on the first column of that key. That query runs in 305ms, so
> more like x2 rather than the reported 300-600x. v18 estimates slightly
> fewer rows than v15, so that might be why it switched plans to the
> bitmap heap scan. That could be down to random sampling from ANALYZE
> finding fewer rows that match the query's WHERE clause in v18.
>
> I'd recommend Clive to try running ANALYZE on the table and seeing if
> the plan changes. Repeat that a few times to see if the Seq Scan plan
> is ever picked. I'd also check if the random_page_cost and
> seq_page_cost settings are the same on both instances and ensure
> enable_seqscan is on.
>
> David