From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-02-11 09:28:47 |
Message-ID: | CAMbWs49DZdSF1NSiD3GD26yb6+uLOwt49HH8UccNcvUP_XfGog@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 10, 2025 at 5:35 PM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
> On 2/10/25 08:29, Richard Guo wrote:
> > Hmm, I'm still a little concerned about whether the resulting joins
> > are legal. Suppose we have a join pattern like the one below.
> >
> > F left join
> > (D1 inner join T on true) on F.b = D1.b
> > left join D2 on F.c = D2.c;
> >
> > For this query, the original joinlist is [F, D1, T, D2]. If we
> > reorder it to [[F, T], D1, D2], the sub-joinlist [F, T] would fail to
> > produce any joins, as the F/T join is not legal.
> >
> > This may not be the pattern we are targeting. But if we intend to
> > support it, I think we need a way to ensure that the resulting joins
> > are legal.
> It's quite possible the PoC patch I posted fails to ensure this, but I
> think the assumption is we'd not reorder joins for dimensions that any
> any join order restrictions (except for the FK join).
Then, we'll need a way to determine if a given relation has join-order
restrictions, which doesn't seem like a trivial task. We do have the
has_join_restriction() function, but it considers any relations
involved in an outer join as having join restrictions, and that makes
it unsuitable for our needs here.
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2025-02-11 09:37:16 | Re: Convert macros to static inline functions |
Previous Message | Richard Guo | 2025-02-11 09:15:24 | Re: Virtual generated columns |