On Wed, Apr 3, 2024 at 11:09 PM David Rowley <dgrowle...@gmail.com> wrote: > On Thu, 4 Apr 2024 at 10:15, David Rowley <dgrowle...@gmail.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