From: | Todd Cook <cookt(at)blackduck(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie>, Sajith Prabhakar Shetty <ssajith(at)blackduck(dot)com> |
Cc: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Postgres: Queries are too slow after upgrading to PG17 from PG15 |
Date: | 2025-07-30 19:48:55 |
Message-ID: | 86572CDF-0BE1-4F24-A173-B8673119BCCA@blackduck.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 7/30/25, 3:17 PM, "Peter Geoghegan" <pg(at)bowt(dot)ie <mailto:pg(at)bowt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2025-07-30 19:50:10 | Re: Postgres: Queries are too slow after upgrading to PG17 from PG15 |
Previous Message | PG Bug reporting form | 2025-07-30 19:20:14 | BUG #19003: A SELECT that does not return a valid table |