Horton

Re: Postgres: Queries are too slow after upgrading to PG17 from PG15

Merlin Moncure <mmoncure@gmail.com>

View thread
From: Merlin Moncure <mmoncure@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Sajith Prabhakar Shetty <ssajith@blackduck.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andrei Lepikhov <lepihov@gmail.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>, Todd Cook <cookt@blackduck.com>
Date: 2025-08-21T02:58:41Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Convert strategies to and from compare types

  2. Enhance nbtree ScalarArrayOp execution.

  3. Improve planning of btree index scans using ScalarArrayOpExpr quals.

  4. Fix planning of btree index scans using ScalarArrayOpExpr quals.

On Wed, Aug 20, 2025 at 7:48 PM Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Tue, Aug 12, 2025 at 12:46 AM Sajith Prabhakar Shetty
> <ssajith@blackduck.com> wrote:
> > I can confirm with full certainty that both VACUUM and ANALYZE were executed on all three instances whose results I shared.
>
> The results that you shared showed "Heap Fetches: 598,916" -- one heap
> fetch per index search (for the problematic index scan).
>
> Perhaps VACUUM ran without being truly effective, due to the removable
> cutoff/horizon being held back by a long running query. Though that
> generally won't happen on a quiescent system -- so it really does look
> like VACUUM hasn't been run.

Try running VACUUM FREEZE.   Do you have a way to frame up a dataset
for testing?

merlin