On Wed, Jun 12, 2024 at 2:11 PM Andres Freund <and...@anarazel.de> wrote: > <can't resist trying if I see overhead> > > In an extreme case i can see a tiny bit of overhead, but not enough to be > worth worrying about. Mostly because we're so profligate in doing > bms_overlap() that cost comparisons don't end up mattering as much - I seem to > recall that being different in the not distant past though.
There are very few things I love more than when you can't resist trying to break my patches and yet fail to find a problem. Granted the latter part only happens once a century or so, but I'll take it. > Aside: I'm somewhat confused by add_paths_to_joinrel()'s handling of > mergejoins_allowed. If mergejoins are disabled we end up reaching > match_unsorted_outer() in more cases than with mergejoins enabled. E.g. we > only set mergejoin_enabled for right joins inside select_mergejoin_clauses(), > but we don't call select_mergejoin_clauses() if !enable_mergejoin and jointype > != FULL. I, what? I agree this logic is extremely confusing, but "we only set mergejoin_enabled for right joins inside select_mergejoin_clauses()" doesn't seem to be true. 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. -- Robert Haas EDB: http://www.enterprisedb.com
