| From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
|---|---|
| To: | Israel Brewster <ijbrewster(at)alaska(dot)edu>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PostgreSQL 15-->18 slowdown? |
| Date: | 2026-06-26 18:14:56 |
| Message-ID: | 2ce465f0-f7f3-4c6a-9f68-b53439416336@aklaver.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 6/26/26 10:58 AM, Israel Brewster wrote:
> In postgreSQL 15, I had the below query that worked quickly. Now, I make
> no claims that the query is the best possible, or even a good query, but
> it DID work, and it did so quickly enough to be un-noticable when running.
>
> Then I upgrade to PostgreSQL 18 - and now the query never completes (as
> in, I get a command timeout after at least half an hour before I get a
> result). Looking at the EXPLAIN (https://explain.depesz.com/s/llAQ
> <https://explain.depesz.com/s/llAQ>) makes it pretty obvious why: we
> have a sequence scan on a large table inside a nested loop - and that
> sequence scan is apparently not short circuiting.
The link provided shows no times or rows, did you pick the correct one?
>
> I tried the obvious: REINDEX database and VACUUM ANALYZE, but neither
> helped. I have my default_statistics_target set to 500 at the moment.
>
> Then I tried SET enable_seqscan = off; Lo and behold, the query ran in
> only 123.888 ms (fun number :-D ) - https://explain.depesz.com/s/K2K9
> <https://explain.depesz.com/s/K2K9>
This one does not show the actual query.
> ---
> Israel Brewster
> Software Engineer
> Alaska Volcano Observatory
> Geophysical Institute - UAF
> 2156 Koyukuk Drive
> Fairbanks AK 99775-7320
> Work: 907-474-5172
> cell: 907-328-9145
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Israel Brewster | 2026-06-26 18:16:14 | Re: PostgreSQL 15-->18 slowdown? |
| Previous Message | Israel Brewster | 2026-06-26 17:58:30 | PostgreSQL 15-->18 slowdown? |