On Wed, Jun 12, 2024 at 2:48 PM Andres Freund <andres@anarazel.de> wrote:
> Sorry, should have been more precise. With "set" I didn't mean set to true,
> but that that it's only modified within select_mergejoin_clauses().
Oh. "set" has more than one relevant meaning here.
> > It starts out true, and always stays true except for right, right-anti, and
> > full joins, where select_mergejoin_clauses() can set it to false. Since the
> > call to match_unsorted_outer() is gated by mergejoin_enabled, you might
> > think that we'd skip considering nested loops on the strength of not being
> > able to do a merge join, but comment "2." in add_paths_to_joinrel explains
> > that the join types for which mergejoin_enabled can end up false aren't
> > supported by nested loops anyway. Still, this logic is really tortured.
>
> Agree that that's the logic - but doesn't that mean we'll consider nestloops
> for e.g. right joins iff enable_mergejoin=false?
No, because that function has its own internal guards. See nestjoinOK.
But don't misunderstand me: I'm not defending the status quo. The
whole thing seems like a Rube Goldberg machine to me.
--
Robert Haas
EDB: http://www.enterprisedb.com