Re: On disable_cost

On Tue, Jul 2, 2024 at 5:39 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> I would be somewhat annoyed if we add another step to that, to also
> disable index-only scans separately. It would be nice if
> enable_indexscan=off would also disable bitmap scans, that would
> eliminate one step from the above. Almost always when I want to disable
> index scans, I really want to disable the use of the index altogether.
> The problem then of course is, how do you force a bitmap scan without
> allowing other index scans, when you want to test them both?
>
> It almost feels like we should have yet another GUC to disable index
> scans, index-only scans and bitmap index scans. "enable_indexes=off" or
> something.

This is an interesting idea, and it seems like it could be convenient.
However, the fact that it's so non-orthogonal is definitely not great.
One problem I've had with going through regression tests that rely on
the enable_* GUCs is that it's often not quite clear what values all
of those GUCs have at a certain point in the test file, because the
statements that set them may be quite a bit higher up in the file and
some changes may also have been rolled back. I've found recently that
the addition of EXPLAIN (SETTINGS) helps with this quite a bit,
because you can adjust the .sql file to use that option and then see
what shows up in the output file. Still, it's annoying, and the same
issue could occur in any other situation where you're using these
GUCs. It's just more confusing when there are multiple ways of turning
something off.

Would we consider merging enable_indexscan, enable_indexonlyscan, and
enable_bitmapscan into something like:

enable_indexes = on | off | { plain | indexonly | bitmap } [, ...]

I feel like that would solve the usability concern that you raise here
while also (1) preserving orthogonality and (2) reducing the number of
GUCs rather than first increasing it. When I first joined the project
there were a decent number of enable_* GUCs, but there's way more now.
Some of them are a little random (which is a conversation for another
day) but just cutting down on the number seems like it might not be
such a bad idea.

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