On 24 Feb 2026, at 12:37, Attila Soki <[email protected]> wrote: > On 24 Feb 2026, at 12:09, Andrei Lepikhov <[email protected]> wro >> 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. > > 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 the default 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 something weird 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
