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
