Re: About the constant-TRUE clause in reconsider_outer_join_clauses

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: About the constant-TRUE clause in reconsider_outer_join_clauses
Дата
Msg-id CAMbWs4-mgy4MpFx3cFM6eCTfaJgRMKQFO0aNoY6vmmNXjUBb8w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: About the constant-TRUE clause in reconsider_outer_join_clauses  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: About the constant-TRUE clause in reconsider_outer_join_clauses  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

On Sat, Mar 25, 2023 at 11:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Richard Guo <guofenglinux@gmail.com> writes:
> Should we instead mark the constant-TRUE clause with required_relids
> plus the OJ relid?

I do not think it matters.

Yeah, I agree that it makes no difference currently.  One day if we want
to replace the is_pushed_down flag with checking to see if a clause's
required_relids includes the OJ being formed in order to tell whether
it's a filter or join clause, I think we'd need to make this change.
 

> Even if the join does become clauseless, it will end up being an
> unqualified nestloop.  I think the join ordering algorithm will force
> this join to be formed when necessary.

We would find *some* valid plan, but not necessarily a *good* plan.
The point of the dummy clause is to ensure that the join is considered
as soon as possible.  That might not be the ideal join order of course,
but we'll consider it among other join orders and arrive at a cost-based
decision.  With no dummy clause, the join order heuristics would always
delay this join as long as possible; so even if another ordering is
better, we'd not find it.

I understand it now.  Thanks for the explanation.

Thanks
Richard

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Initial Schema Sync for Logical Replication
Следующее
От: Tom Lane
Дата:
Сообщение: Re: About the constant-TRUE clause in reconsider_outer_join_clauses