On Mon, Jun 18, 2018 at 3:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> But if we feel this is worth
> pulling into core, I think something along the lines of a GUC listing
> indexes to ignore for planning purposes might be a better design.
> It'd certainly dodge the issues you mentioned about lack of mutability
> of pg_index entries.


​While adding a mutable column to pg_index​ is probably ideal having a
pg_index_visible table related one-to-one (optional?) with pg_index.  MySQL
has, and we would probably want, a GUC to control whether to check the
table for visibility.

Reading the MySQL description for this one use case posited is a DBA
wanting to remove an index and see which queries appear in their duration
limit log (probably in combination with auto-explain).

An SQL interface to the feature seems desirable.  On that front VISIBLE and
INVISIBLE are the pre-existing keywords for MySQL.

As long as BEGIN-ALTER INDEX-ROLLBACK works as expected I wouldn't see any
need for a GUC accepting text inputs.  That said, somehow making "ALTER
INDEX LOCAL name INVISIBLE" work and having it auto-revert back to visible
as transaction end would provide for the one major advantage of an
in-session SET.

David J.

Reply via email to