Re: On disable_cost

On Mon, Oct 7, 2024 at 6:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I don't buy your argument that this case is so special that it
> warrants preserving disable_cost.  I certainly didn't think it
> was special when I added it.

That's fair. I'm telling you what I think, not what you have to think. :-)

> There may be another way to do this that doesn't rely on disabling
> the path in the same way as the user-accessible knobs do, but
> I don't really believe it's worth the trouble to think of one.
> And I definitely don't want to keep disable_cost around even for
> just one usage, because then we've not fixed the user-experience
> aspect of this (that is, "why does this plan have a ridiculously high
> cost?"), nor have we fixed all the concerns you had about higher-level
> planning decisions being skewed by that cost.

We don't represent the memory usage of a plan in general, so the
uses-too-much-memory case has to be represented in some other way,
either incrementing disabled nodes or adding something to the cost.
Neither is wholly accurate, in my view. We either conflate too much
memory usage with "runs for a long time" or with "the user said not to
do it".

What I'm actually worried about here is that getting rid of this last
use of disable_cost will interact badly with the work I've proposed
over on the "allowing extensions to control planner behavior" thread.
While the exact details of what we do there have yet to be finalized,
the concept definitely revolves around extensions having a way to
disable certain paths. If an extension gets to control the disabled
nodes knob and the planner gets to control the cost knob, the
extension can be certain of being able to choose the outcome it wants
out of those that are possible. If the core planner also fiddles with
the disabled nodes knob, that is no longer certain. I don't want
extensions to have to invent some weird hack to work around that case,
and I'm sure neither of us wants to have a third thing in core that is
an even-higher-order component of the cost than disabled_nodes.

> One other point here is that if disable_cost remains exposed as a
> global variable (as it is in HEAD), there is no reason to expect
> that any extensions that are using it will get on board with the
> new approach.

Yes, I think if we keep this one use of disable_cost we should rename
it to something like too_much_memory_cost or whatever.

-- 
Robert Haas
EDB: http://www.enterprisedb.com