Re: unstable query plan on pg 16,17,18

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Attila Soki <atiware(at)gmx(dot)net>, Andrei Lepikhov <lepihov(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: unstable query plan on pg 16,17,18
Date: 2026-02-26 20:53:57
Message-ID: da00062f06e909ebd9250edcea9fee58bb626392.camel@cybertec.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, 2026-02-26 at 17:15 +0100, Attila Soki wrote:
> Increasing the statistics of dp_end_dat did not helped. With statistic 1000
> I was not able to get a good plan without setting join_collapse_limit=7

Reducing "join_collapse_limit" dumbs down the optimizer, so you are getting a good plan
by accident. I mean, you can try to rewrite the query so that the tables are written
in the order in which they should be joined in the good plan, then set "join_collapse_limit"
to 1. That may be a solution if you cannot find a better one.

Still, the bad estimate that I indicated in [1] is worrysome, and I don't quite
understand it. Could you show the result of the simplified query that I suggested?

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

If I were you, I'd focus on getting PostgreSQL to estimate that correctly.

Yours,
Laurenz Albe

[1]: https://postgr.es/m/b2e372392b8a022da81b95b7c823a5729d7fd70f.camel%40cybertec.at

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Andrei Lepikhov 2026-02-27 08:15:33 Re: unstable query plan on pg 16,17,18
Previous Message Attila Soki 2026-02-26 16:22:47 Re: unstable query plan on pg 16,17,18