Re: should we have a fast-path planning for OLTP starjoins? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: should we have a fast-path planning for OLTP starjoins?
Date
Msg-id 1679406.1762713753@sss.pgh.pa.us
Whole thread Raw
In response to Re: should we have a fast-path planning for OLTP starjoins?  (Tomas Vondra <tomas@vondra.me>)
Responses Re: should we have a fast-path planning for OLTP starjoins?
List pgsql-hackers
Tomas Vondra <tomas@vondra.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.

> 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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: should we have a fast-path planning for OLTP starjoins?
Next
From: Peter Geoghegan
Date:
Subject: Re: Don't synchronously wait for already-in-progress IO in read stream