Re: should we have a fast-path planning for OLTP starjoins?
От | Richard Guo |
---|---|
Тема | Re: should we have a fast-path planning for OLTP starjoins? |
Дата | |
Msg-id | CAMbWs49DZdSF1NSiD3GD26yb6+uLOwt49HH8UccNcvUP_XfGog@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: should we have a fast-path planning for OLTP starjoins? (Tomas Vondra <tomas@vondra.me>) |
Ответы |
Re: should we have a fast-path planning for OLTP starjoins?
|
Список | pgsql-hackers |
On Mon, Feb 10, 2025 at 5:35 PM Tomas Vondra <tomas@vondra.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
В списке pgsql-hackers по дате отправления: