Re: Invisible Indexes

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Invisible Indexes
Date: 2018-06-18 22:27:15
Message-ID: CAKFQuwZJrtTo0bvRjHU9zhvcZJsM3pSfdE5HhUz6Yc8ombAf4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 18, 2018 at 3:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2018-06-18 22:35:15 Re: Invisible Indexes
Previous Message Robert Treat 2018-06-18 22:21:43 Re: Remove mention in docs that foreign keys on partitioned tables are not supported