| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | James Hunter <james(dot)hunter(dot)pg(at)gmail(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: should we have a fast-path planning for OLTP starjoins? |
| Date: | 2025-11-09 18:42:33 |
| Message-ID: | 1679406.1762713753@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2025-11-09 19:51:08 | Re: Don't synchronously wait for already-in-progress IO in read stream |
| Previous Message | Tomas Vondra | 2025-11-09 18:14:57 | Re: should we have a fast-path planning for OLTP starjoins? |