Re: On disable_cost
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Greg Sabino Mullane <htamfids@gmail.com>, Zhenghua Lyu <zlyu@vmware.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-04-02T16:58:18Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Apr 2, 2024 at 11:54 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I suspect that it'd behave poorly when there are both disabled and >> promoted sub-paths in a tree, for pretty much the same reasons you >> explained just upthread. > Hmm, can you explain further? I think essentially you'd be maximizing > #(promoted notes)-#(disabled nodes), but I have no real idea whether > that behavior will be exactly what people want or extremely > unintuitive or something in the middle. It seems like it should be > fine if there's only promoting or only disabling or if we can respect > both the promoting and the disabling, assuming we even want to have > both, but I'm suspicious that it will be weird somehow in other cases. > I can't say exactly in what way, though. Do you have more insight? Not really. But if you had, say, a join of a promoted path to a disabled path, that would be treated as on-par with a join of two regular paths, which seems like it'd lead to odd choices. Maybe it'd be fine, but my gut says it'd likely not act nicely. As you say, it's a lot easier to believe that only-promoted or only-disabled situations would behave sanely. regards, tom lane
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