Message-ID: <b2e372392b8a022da81b95b7c823a5729d7fd70f.camel@cybertec.at>
Subject: Re: unstable query plan on pg 16,17,18
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Attila Soki <atiware@gmx.net>, pgsql-performance@postgresql.org
Date: Mon, 23 Feb 2026 20:59:41 +0100
In-Reply-To: <1695A676-062B-47C5-B302-91E2357DC874@gmx.net>
References: <ECA94B5A-E5B4-45F7-B1B4-9BF754083164@gmx.net>
	 <e94e4d006975792d72e667bbd0499f9ddec4ed58.camel@cybertec.at>
	 <1695A676-062B-47C5-B302-91E2357DC874@gmx.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/b2e372392b8a022da81b95b7c823a5729d7fd70f.camel%40cybertec.at>
Precedence: bulk

On Mon, 2026-02-23 at 16:10 +0100, Attila Soki wrote:
> > On 23 Feb 2026, at 10:41, Laurenz Albe <laurenz.albe@cybertec.at> wrote=
:
> >=20
> > On Mon, 2026-02-23 at 10:37 +0100, Attila Soki wrote:
> > > When upgrading from PostgreSQL 14.4, I noticed that one of my somewha=
t complex
> > > analytical queries sometimes gets an inefficient plan under PostgreSQ=
L 16, 17, and 18.
> > > Under 14.4, the query runs with a stable plan and completes in 19 to =
22 seconds.
> > > In newer versions, the plan seems to be unstable, sometimes the query=
 completes
> > > in 17 to 20 seconds, sometimes it runs for 5 to 18 minutes with the i=
nefficient plan.
> > > This also happens even if the data is not significantly changed.
> >=20
> > This is very likely owing to a bad estimate.
> >=20
> > Could you turn on "track_io_timing" and send us the EXPLAIN (ANALYZE, B=
UFFERS) output
> > for both the good and the bad plan?
>=20
> Thank you for your reply. Here are the two explains.
> In order to be able to publish the plans here, I have obfuscated the tabl=
e and field names, but this is reversible, so I can provide more info if ne=
eded.
>=20
> plan-ok:
> https://explain.depesz.com/s/hQvM
>=20
> plan-wrong:
> https://explain.depesz.com/s/uLvl

Thanks.

The difference in the plans is under the "Subquery Scan on odg", starting w=
ith
plan node 50 (everything under the "Sort").  I suspect that the mis-estimat=
e
that is at the root of the problem is here:

->  Index Scan using table_k_late_spec_dp_end_dat_key on schema1.table_k ka=
l  (... rows=3D196053 ...) (... rows=3D471.00 ...)
      Index Cond: (kal.dp_end_dat < ('now'::cstring)::date)
      Index Searches: 1
      Buffers: shared hit=3D230 read=3D49
      I/O Timings: shared read=3D0.142

PostgreSQL overestimates the row count by a factor of over 400.
Try to fix that estimate and see if that gets PostgreSQL to do the right th=
ing.

Perhaps a simple ANALYZE on the table can do the trick.

The right side of the comparison looks awkward, as if you wrote 'now'::text=
::date
My experiments show that PostgreSQL v18 estimates well even with such a wei=
rd
condition, but perhaps if you write "current_date" instead, you'd get bette=
r results.

I'd play just with a query like

  EXPLAIN (ANALYZE)
  SELECT * FROM schema1.table_k AS kal
  WHERE dp_end_dat < current_date;

until I get a good estimate.

Yours,
Laurenz Albe