From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Todd Cook <cookt(at)blackduck(dot)com>, 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-31 02:39:31 |
Message-ID: | CAApHDvq4YjLsNnX8PcFkPBaCmCgoW6j-HR2XxMaOm+6AFUOBUw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, 31 Jul 2025 at 08:14, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> 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.
Even just presorting the IN list constants would make it better. If I
manually adjust the recreator query to sort the items in both IN
lists, I get:
Execution Time: 263.365 ms
vs:
Execution Time: 804.377 ms
Of course, the qsort_arg() call still happens, it'll hit qsort_arg's
presorted short-circuit case and will do very little.
I've not looked in great detail, but I did wonder if it's worth
adjusting ExecIndexBuildScanKeys() to sort the array in a
ScalarArrayOpExpr when it's Const beforehand. That might be a bit of
wasted effort if there's just one scan, however.
David
Attachment | Content-Type | Size |
---|---|---|
sorted_in_lists.sql | application/octet-stream | 3.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2025-07-31 02:49:16 | Re: Postgres: Queries are too slow after upgrading to PG17 from PG15 |
Previous Message | David G. Johnston | 2025-07-30 21:38:16 | Re: BUG #19003: A SELECT that does not return a valid table |