Re: About the constant-TRUE clause in reconsider_outer_join_clauses - Mailing list pgsql-hackers

From Richard Guo
Subject Re: About the constant-TRUE clause in reconsider_outer_join_clauses
Date
Msg-id CAMbWs4-mgy4MpFx3cFM6eCTfaJgRMKQFO0aNoY6vmmNXjUBb8w@mail.gmail.com
Whole thread Raw
In response to Re: About the constant-TRUE clause in reconsider_outer_join_clauses  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: About the constant-TRUE clause in reconsider_outer_join_clauses  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Initial Schema Sync for Logical Replication
Next
From: Tom Lane
Date:
Subject: Re: About the constant-TRUE clause in reconsider_outer_join_clauses