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

  1. Doc: add detail about EXPLAIN's "Disabled" property

  2. Adjust EXPLAIN's output for disabled nodes

  3. Fix order of parameters in a cost_sort call

  4. Show number of disabled nodes in EXPLAIN ANALYZE output.

  5. Treat number of disabled nodes in a path as a separate cost metric.

  6. Remove grotty use of disable_cost for TID scan plans.