Horton

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

Todd Cook <cookt@blackduck.com>

View thread
From: Todd Cook <cookt@blackduck.com>
To: Peter Geoghegan <pg@bowt.ie>, Sajith Prabhakar Shetty <ssajith@blackduck.com>
Cc: Andrei Lepikhov <lepihov@gmail.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2025-07-30T19:48:55Z
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 7/30/25, 3:17 PM, "Peter Geoghegan" <pg@bowt.ie <mailto:pg@bowt.ie>> wrote:
    Perhaps Tom can weigh-in here. I removed code that generated these
    alternative index paths from the planner because its original
    justification (see bugfix commit a4523c5a, a follow-up to bugfix
    commit 807a40c5) no longer applied. Perhaps this should be revisited
    now, or perhaps the issue should be ameliorated on the nbtree side. Or
    maybe we should just do nothing -- the issue can be worked around in
    the application itself.

I work at the same company as Sajith, but on a different product.  The reproducer he
provided is just a sample; it's not the only problem.  Load testing in my team shows
that PG 17 is about 4x slower than PG 15 across the board.  It's bordering on unusable
for production deployments.

Unfortunately, the load testing setup doesn't really help isolate individual, regressing
queries.  However, I'm more than willing to help support any further investigation if
needed or helpful.

-- todd