Re: On disable_cost

On Wed, Apr 3, 2024 at 11:09 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Thu, 4 Apr 2024 at 10:15, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > In short, I don't find it strange that disabling one node type results
> > in considering another type that we'd otherwise not consider in cases
> > where we assume that the disabled node type is always superior and
> > should always be used when it is possible.
>
> In addition to what I said earlier, I think the current
> enable_indexonlyscan is implemented in a way that has the planner do
> what it did before IOS was added. I think that goal makes sense with
> any patch that make the planner try something new. We want to have
> some method to get the previous behaviour for the cases where the
> planner makes a dumb choice or to avoid some bug in the new feature.

I see the logic of this, and I agree that the resulting behavior might
be more intuitive than what I posted before. I'll do some experiments.

> I think using that logic, the current scenario with enable_indexscan
> and enable_indexonlyscan makes complete sense. I mean, including
> enable_indexscan=0 adding disable_cost to IOS Paths.

This, for me, is a bridge too far. I don't think there's a real
argument that "what the planner did before IOS was added" was add
disable_cost to the cost of index-only scan paths. There was no such
path type. Independently of that argument, I also think the behavior
of a setting needs to be something that a user can understand. Right
now, the documentation says:

Enables or disables the query planner's use of index-scan plan types.
The default is on.
Enables or disables the query planner's use of index-only-scan plan
types (see Section 11.9). The default is on.

I do not think that a user can be expected to guess from these
descriptions that the first one also affects index-only scans, or that
the two GUCs disable their respective plan types in completely
different ways. Granted, the latter inconsistency affects a whole
bunch of these settings, not just this one, but still.

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