Re: Invisible Indexes

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Invisible Indexes
Дата
Msg-id 20180618215635.m5vrnxdxhxytvmcm@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Invisible Indexes  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Ответы Re: Invisible Indexes  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
On 2018-06-18 17:50:44 -0400, Andrew Dunstan wrote:
> 
> 
> On 06/18/2018 05:46 PM, Jaime Casanova wrote:
> > On 18 June 2018 at 16:36, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:
> > > This is a MySQL feature, where an index is not considered by the planner.
> > > Implementing it should be fairly straightforward, adding a new boolean to
> > > pg_index, and options to CREATE INDEX and ALTER INDEX. I guess VISIBLE would
> > > become a new unreserved keyword.
> > > 
> > > The most obvious use case is to see what the planner does when the index is
> > > not visible, for example which other index(es) it might use. There are
> > > probably other cases where we might want an index to enforce a constraint
> > > but not to be used in query planning.
> > > 
> > > So, do we want this feature? If we do I'll go ahead and prepare a patch.
> > > 
> > should pg_index.indisvalid works for this? in that case you only need
> > the syntax for it...
> > 
> 
> 
> I thought about that. But I think these are more or less orthogonal.  I
> doubt it will involve lots of extra code, though.

Be careful about that - currently it's not actually trivially possible
to ever update pg_index rows. No, I'm not kidding
you. pg_index.indexcheckxmin relies on the pg_index row's xmin. If you
have ALTER do a non inplace update, you'll break things.

Greetings,

Andres Freund


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [WIP] [B-Tree] Retail IndexTuple deletion
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Invisible Indexes