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

On 23/2/26 18:03, Attila Soki wrote:
>> On 23 Feb 2026, at 16:54, Andrei Lepikhov <lepihov@gmail.com> wrote:
> see my previous answer:
> https://www.postgresql.org/message-id/1695A676-062B-47C5- 
> B302-91E2357DC874%40gmx.net <https://www.postgresql.org/message- 
> id/1695A676-062B-47C5-B302-91E2357DC874%40gmx.net>
> 
> but here are the plans again:
> In order to be able to publish the plans here, I have obfuscated the 
> table and field names, but this is reversible, so I can provide more 
> info if needed.
> 
> plan-ok:
> https://explain.depesz.com/s/hQvM <https://explain.depesz.com/s/hQvM>
> 
> plan-wrong:
> https://explain.depesz.com/s/uLvl <https://explain.depesz.com/s/uLvl>

Thanks. But I meant your 'good' plan built by the PG14. I think a new 
feature invented later has added some problems.

Current conjecture is the following. As I see, the main problem is with 
Right Hash Join:
-> Hash Right Join (cost=210369.25..210370.30 rows=8 width=99)
Its inner side (Hash table) is rebuilt multiple times (around 1k) due to 
an external parameter (gauf_1.id) in the subtree. It looks like a 
disaster, and before I thought we don't build hash tables over 
parameterised query trees at all.

So, let me discover a little more, but your PG14 explain could add more 
details here.

-- 
regards, Andrei Lepikhov,
pgEdge