On 11/9/25 19:42, Tom Lane wrote: > Tomas Vondra <[email protected]> writes: >> If I set join_collapse_limit=1, then standard_join_search() only sees >> problems of size 2, i.e. (list_length(initial_rels) == 2). And we only >> look at has_join_restriction() *inside* these small problems, i.e. the >> jointree must not be deconstructed in a way that would violate this. > >> Doesn't that mean deconstruct_jointree() has to somehow "consider" the >> join restrictions (even if not explicitly). > > It mustn't build subproblems that don't have any legal solutions, sure. > But that is automatic given that it only folds up within the syntactic > structure --- it doesn't go combining rels from random places within > the jointree. >
Ah, I see. I didn't realize it's driven purely by the syntactic structure, I got convinced it's aware of more stuff. But yeah, this means it can't help the patch. >> It that's the case, could we >> maybe leverage that, eliminating the need to call has_join_restriction? > > Don't see how. Once we've folded an outer join into an upper > subproblem, some but (usually) not all of the join orders within that > subproblem will be legal. > > It might be that we could make has_join_restriction and friends > faster/simpler with some other representation of the join tree. > I've not really thought hard about alternatives. > No idea. I'm not familiar enough with this to have good ideas on how to rework it, and I assume has_join_restriction will be cheap enough for this patch. regards -- Tomas Vondra
