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

On 24 Feb 2026, at 12:37, Attila Soki <atiware(at)gmx(dot)net> wrote:
> On 24 Feb 2026, at 12:09, Andrei Lepikhov <lepihov(at)gmail(dot)com> 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