Re: should we have a fast-path planning for OLTP starjoins?

On 11/9/25 19:42, Tom Lane wrote:
> Tomas Vondra <tomas(at)vondra(dot)me> 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