Message-ID: <0dd76506-053e-4a30-9f95-9dc324e8e1fb@gmail.com>
Date: Tue, 24 Feb 2026 12:09:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: unstable query plan on pg 16,17,18
To: Attila Soki <atiware@gmx.net>
Cc: pgsql-performance@postgresql.org, Laurenz Albe <laurenz.albe@cybertec.at>
References: <ECA94B5A-E5B4-45F7-B1B4-9BF754083164@gmx.net>
 <e94e4d006975792d72e667bbd0499f9ddec4ed58.camel@cybertec.at>
 <64ddfe83-317c-4cf1-b04f-cb74d9f40629@gmail.com>
 <529E2365-6C3F-4BDA-9625-312F3A023C5B@gmx.net>
 <5bace3e5-3d6b-4f81-92a9-9ff4e9e5de53@gmail.com>
 <1C445A2F-3256-4F04-B55D-9850581FF39A@gmx.net>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <1C445A2F-3256-4F04-B55D-9850581FF39A@gmx.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/0dd76506-053e-4a30-9f95-9dc324e8e1fb%40gmail.com>
Precedence: bulk

On 24/2/26 10:16, Attila Soki wrote:
> On 23 Feb 2026, at 21:25, Andrei Lepikhov <lepihov@gmail.com> wrote:
>> 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.
> 
> Sorry, I misunderstood that.
> here is the pg14.4 explain

This update gives us more useful details. In PG14, the join search 
problem involved at most 9 relations. In PG19, the maximum is now 18 
joins. Do you know what your join_collapse_limit is set to? It looks 
like subplan pull-ups have made things more complex.
First, we should look into any possible 'rescan cost' issues on our side 
as developers.
On your end, please check the join_collapse_limit setting. If needed, 
try increasing it to around 20. This might help.

-- 
regards, Andrei Lepikhov,
pgEdge