[ Don't have time to read the v4 patch right now, but a couple of quick responses: ]
Tomas Vondra <[email protected]> writes: > On 9/23/25 21:46, Tom Lane wrote: >> I'd be slightly inclined to put the GUC test there, too: >> >> + if (enable_starjoin_join_search) >> + joinlist = starjoin_adjust_joins(root, joinlist); > I'm not sure I like this very mcuh. No other call in query_planner() > does it like that. Most don't have such GUC, but at least > remove_useless_self_joins does, and it still doesn't check it here. Fair enough, it was just a suggestion. > When thinking about this, I realized the has_join_restriction() is only > ever used in join_search_one_level(), i.e. when dealing with each small > join order problem. Doesn't this mean the deconstructed jointree must > already consider the restrictions in some way? I don't see any explicit > mentions of such join order restrictions in deconstruct_recurse. It must > not violate any ordering restrictions by splitting the joins in a > "wrong" way, right? If I set join_collapse_limit=1 it still needs to > satisfy all the rules. Performing outer joins in syntactic order is always OK by definition, and setting join_collapse_limit to 1 just forces that to happen. So I guess you could say that the original jointree "considers the restrictions", and it's only after we flatten an outer join's two sides into a joinlist (along with other rels) that we have to worry. Or is that not what you meant? regards, tom lane
