Robert Haas <robertmh...@gmail.com> writes: > On Tue, Apr 2, 2024 at 10:04 AM Greg Sabino Mullane <htamf...@gmail.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