| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Todd Cook <cookt(at)blackduck(dot)com> |
| Cc: | Sajith Prabhakar Shetty <ssajith(at)blackduck(dot)com>, 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 20:14:25 |
| Message-ID: | CAH2-WznXv9NPLOJ3PEcVmnDY6P8HLGWn45DUQD4uROjvDb_JbA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Jul 30, 2025 at 3:48 PM Todd Cook <cookt(at)blackduck(dot)com> wrote:
> 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.
I suggest that you rewrite affected queries to make them join against
a VALUES() with the same constants as those currently used in the
larger IN() list. If you're not sure whether the set of constants from
the application will be reliably unique, you can use DISTINCT to make
sure.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-07-30 21:34:41 | Re: BUG #19003: A SELECT that does not return a valid table |
| Previous Message | Peter Geoghegan | 2025-07-30 19:50:10 | Re: Postgres: Queries are too slow after upgrading to PG17 from PG15 |