On Wed, Jun 12, 2024 at 2:48 PM Andres Freund <and...@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
