On Mon, Oct 7, 2024 at 6:41 PM Tom Lane <t...@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
