Re: Invisible Indexes - Mailing list pgsql-hackers

From David Rowley
Subject Re: Invisible Indexes
Date
Msg-id CAKJS1f_L7y_BTGESp5Qd6BSRHXP0mj3x9O9C_U27GU478UwpBw@mail.gmail.com
Whole thread Raw
In response to Re: Invisible Indexes  (Andres Freund <andres@anarazel.de>)
Responses Re: Invisible Indexes  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On 19 June 2018 at 09:56, Andres Freund <andres@anarazel.de> wrote:
> 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.

Couldn't we just add a dedicated xid field to pg_index to solve that,
one which does not change when the row is updated?

Or would it be insanely weird to just not allow setting or unsetting
this invisible flag if indcheckxmin is true?  I can't imagine there
will be many people adding an index and not wanting to use it while
it's still being created.  I think the use case here is mostly people
wanting to test dropping indexes before they go and remove that 1TB
index that will take days to build again if they're wrong.


-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: peripatus build failures....
Next
From: Peter Geoghegan
Date:
Subject: Re: Invisible Indexes