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
|
Список | 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.
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
Thanks
Richard
В списке pgsql-hackers по дате отправления: