Re: On disable_cost
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, David Rowley <dgrowleyml@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-06-12T18:48:35Z
Lists: pgsql-hackers
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
Commits
-
Doc: add detail about EXPLAIN's "Disabled" property
- 84b8fccbe5c2 18.0 landed
-
Adjust EXPLAIN's output for disabled nodes
- 161320b4b960 18.0 landed
-
Fix order of parameters in a cost_sort call
- 87b6c3c0b703 18.0 landed
-
Show number of disabled nodes in EXPLAIN ANALYZE output.
- c01743aa4866 18.0 landed
-
Treat number of disabled nodes in a path as a separate cost metric.
- e22253467942 18.0 landed
-
Remove grotty use of disable_cost for TID scan plans.
- e4326fbc60c4 18.0 landed