From: Israel Brewster <ijbrewster@alaska.edu>
Message-Id: <9FB992C2-0A1D-4BFE-8066-77F130471B9B@alaska.edu>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4AA73510-97BE-4B9F-BC0C-24F31AB75FF6"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: PostgreSQL 15-->18 slowdown?
Date: Fri, 26 Jun 2026 10:19:06 -0800
In-Reply-To: <2ce465f0-f7f3-4c6a-9f68-b53439416336@aklaver.com>
Cc: PostgreSQL General <pgsql-general@lists.postgresql.org>
To: Adrian Klaver <adrian.klaver@aklaver.com>
References: <4A6D9280-1409-42A8-9A1F-99E2A558E2BB@alaska.edu>
 <2ce465f0-f7f3-4c6a-9f68-b53439416336@aklaver.com>
Archived-At: 
 <https://www.postgresql.org/message-id/9FB992C2-0A1D-4BFE-8066-77F130471B9B%40alaska.edu>
Precedence: bulk


--Apple-Mail=_4AA73510-97BE-4B9F-BC0C-24F31AB75FF6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Jun 26, 2026, at 10:14=E2=80=AFAM, Adrian Klaver =
<adrian.klaver@aklaver.com> wrote:
>=20
>=20
>=20
> 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.
>=20
> 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 =3D 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>
>=20
> This one does not show the actual query.

Right, sorry. It=E2=80=99s the same query as in the first one though. =
Only difference is sequence scan off.

---
Israel Brewster
Software Engineer
Alaska Volcano Observatory=20
Geophysical Institute - UAF=20
2156 Koyukuk Drive=20
Fairbanks AK 99775-7320
Work: 907-474-5172
cell:  907-328-9145


>=20
>=20
>> ---
>> 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
>=20


--Apple-Mail=_4AA73510-97BE-4B9F-BC0C-24F31AB75FF6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;">On Jun 26, 2026, at 10:14=E2=80=AFAM, =
Adrian Klaver &lt;adrian.klaver@aklaver.com&gt; =
wrote:<br><div><blockquote type=3D"cite"><br =
class=3D"Apple-interchange-newline"><div><div><br><br>On 6/26/26 10:58 =
AM, Israel Brewster wrote:<br><blockquote type=3D"cite">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.<br>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 =
&lt;https://explain.depesz.com/s/llAQ&gt;)&nbsp;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.<br></blockquote><br>The link provided shows no times or =
rows, did you pick the correct one?<br><blockquote type=3D"cite">I tried =
the obvious: REINDEX database and VACUUM ANALYZE, but neither helped. I =
have my default_statistics_target set to 500 at the moment.<br>Then I =
tried SET enable_seqscan =3D off; Lo and behold, the query ran in only =
123.888 ms (fun number :-D ) - https://explain.depesz.com/s/K2K9 =
&lt;https://explain.depesz.com/s/K2K9&gt;<br></blockquote><br>This one =
does not show the actual =
query.<br></div></div></blockquote><div><br></div><div>Right, sorry. =
It=E2=80=99s the same query as in the first one though. Only difference =
is sequence scan off.</div><div><br></div><div><div><div dir=3D"auto" =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><div>---</div><div>Israel =
Brewster<br>Software Engineer<br>Alaska Volcano =
Observatory&nbsp;<br>Geophysical Institute - UAF&nbsp;<br>2156 Koyukuk =
Drive&nbsp;<br>Fairbanks AK 99775-7320</div><div>Work: =
907-474-5172<br>cell: =
&nbsp;907-328-9145</div><div><br></div></div></div></div><br><blockquote =
type=3D"cite"><div><div><br><br><blockquote type=3D"cite">---<br>Israel =
Brewster<br>Software Engineer<br>Alaska Volcano =
Observatory<br>Geophysical Institute - UAF<br>2156 Koyukuk =
Drive<br>Fairbanks AK 99775-7320<br>Work: 907-474-5172<br>cell: =
&nbsp;907-328-9145<br></blockquote><br></div></div></blockquote></div><br>=
</body></html>=

--Apple-Mail=_4AA73510-97BE-4B9F-BC0C-24F31AB75FF6--