Re: On disable_cost

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