Re: On disable_cost - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: On disable_cost
Date
Msg-id CAKAnmm+1TbqTnZ0HtN0ir5BUX=yHEWCCb5U_N_YkKk_ytX6xhA@mail.gmail.com
Whole thread Raw
In response to Re: On disable_cost  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: On disable_cost  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Apr 1, 2024 at 7:54 PM Robert Haas <robertmhaas@gmail.com> wrote:
What I think we're mostly doing in the regression tests is shutting
off every relevant type of plan except one. I theorize that what we
actually want to do is tell the planner what we do want to happen,
rather than what we don't want to happen, but we've got this weird set
of GUCs that do the opposite of that and we're super-attached to them
because they've existed forever.

So rather than listing all the things we don't want to happen, we need a way to force (nay, highly encourage) a particular solution. As our costing is a based on positive numbers, what if we did something like this in costsize.c?

 Cost        disable_cost = 1.0e10;
 Cost        promotion_cost = 1.0e10; // or higher or lower, depending on how strongly we want to "beat" disable_costs effects.
...

    if (!enable_seqscan)
        startup_cost += disable_cost;
    else if (promote_seqscan)
        startup_cost -= promotion_cost; // or replace "promote" with "encourage"?


Cheers,
Greg

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: remaining sql/json patches
Next
From: Bharath Rupireddy
Date:
Subject: Re: Synchronizing slots from primary to standby