On 24 Feb 2026, at 12:37, Attila Soki <atiware@gmx.net> wrote:
> On 24 Feb 2026, at 12:09, Andrei Lepikhov <lepihov@gmail.com> wro
>> This update gives us more useful details. In PG14, the join search problem involved at most 9 relations. In PG19,
themaximum is now 18 joins. Do you know what your join_collapse_limit is set to? It looks like subplan pull-ups have
madethings 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.
>
> join_collapse_limit is not set, so it is the default, 8
> I will try if something around 20 helps.
I tried it with join_collapse_limit 10,15, 20 with no success,
but with join_collapse_limit 1, 5, 7 I get the good plan.
Then I set join_collapse_limit back to default and flipped the plan again with vacuumdb until i get the good plan with
thedefault join_collapse_limit.
Then I tried to increase join_collapse_limit until the query (or planning) runs longer than 28 sec.
I tried 1, 5 ,7, 8, 9 ,10, 15, 20, 40, 100 but the query runs stable with 17-20 sec runtime. so there is still
somethingweird with the statistics.
Now with join_collapse_limit=7 works for me and I am not able to flip the plan. makes that sense?
should I still test with increased statistic on table_k.dp_end_dat as Laurenz suggested?
I could now share some general infos about the query, if you still interested.
thanks.
regards
Attila
