Hi,
On 2024-06-12 14:33:31 -0400, Robert Haas wrote:
> 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.
:)
Too high cost in path cost comparison is what made me look at the PG code for
the first time, IIRC :)
> > 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.
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().
> 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?
Greetings,
Andres Freund