Re: On disable_cost

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Apr 2, 2024 at 10:04 AM Greg Sabino Mullane <htamfids(at)gmail(dot)com> wrote:
>> if (!enable_seqscan)
>> startup_cost += disable_cost;
>> else if (promote_seqscan)
>> startup_cost -= promotion_cost; // or replace "promote" with "encourage"?

> I'm pretty sure negative costs are going to create a variety of
> unpleasant planning artifacts.

Indeed. It might be okay to have negative values for disabled-ness
if we treat disabled-ness as a "separate order of infinity", but
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.

> I think the only reason we're
> driving this off of costing today is that making add_path() more
> complicated is unappealing, mostly on performance grounds, and if you
> add disabled-ness (or promoted-ness) as a separate axis of value then
> add_path() has to know about that on top of everything else.

It doesn't seem to me that it's a separate axis of value, just a
higher-order component of the cost metric. Nonetheless, adding even
a few instructions to add_path comparisons sounds expensive. Maybe
it'd be fine, but we'd need to do some performance testing.

regards, tom lane