Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 2, 2024 at 10:57 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> I fear this will break people's applications, if they are currently
>> forcing a sequential scan with "set enable_indexscan=off". Now they will
>> need to do "set enable_indexscan=off; set enable_indexonlyscan=off" for
>> the same effect. Maybe it's acceptable, disabling sequential scans to
>> force an index scan is much more common than the other way round.
> But I don't think one can have a GUC called enable_indexscan and
> another GUC called enable_indexonlyscan and argue that it's OK for the
> former one to affect both kinds of scans. That's extremely confusing
> and, well, just plain wrong.
FWIW, I disagree completely. I think it's entirely natural to
consider bitmap index scans to be a subset of index scans, so that
enable_indexscan should affect both. I admit that the current set
of GUCs doesn't let you force a bitmap scan over a plain one, but
I can't recall many people complaining about that. I don't follow
the argument that this definition is somehow unmaintainable, either.
>> Could we cram it into the "cost=... rows=..." part? And perhaps a marker
>> that a node was disabled would be more user friendly than showing the
>> cumulative count? Something like:
> The problem is that we'd have to derive that.
The other problem is it'd break an awful lot of client code that knows
the format of those lines. (Sure, by now all such code should have
been rewritten to look at JSON or other more machine-friendly output
formats ... but since we haven't even done that in our own regression
tests, we should know better than to assume other people have done it.)
I'm not really convinced that we need to show anything about this.
regards, tom lane
