> Don't get me wrong, it would be an improvement to have some type of
> mechanism that can move you from almost 100% to 100%, but the real
> problem is how do you SAFELY get to almost 100% in the first place?
This big use case is precisely the "almost 100% to 100%" confidence problem.
Usually, users have done their homework, they've analyzed
workloads, tuned queries and maybe created a better index. Now, they see some
indexes that are unused or underused. In the current state, the only
option is to drop the
index. But if that turns out to be a mistake, they have to rebuild it, which
can be slow and disruptive. With this feature, If making the index
invisible causes
problems, they can quickly make it visible again without needing to
rebuild anything.
Also, users coming from other databases, both commercial and open source, are
already used to this kind of setup: an ALTER command for visibility, plus a
parameter to control whether invisible indexes are used on a per session level.
So we're not inventing something new here; we're following a well-known and
useful pattern that makes life easier, especially for users migrating to
Postgres.
I am still trying to understand. Do you think the ALTER command is not useful?
or, do you think the GUC is all we need and it should be more granular?
or maybe something different?
--
Sami
