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