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 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. David
