| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Invisible Indexes |
| Date: | 2018-07-05 01:26:29 |
| Message-ID: | CAKJS1f_L7y_BTGESp5Qd6BSRHXP0mj3x9O9C_U27GU478UwpBw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 19 June 2018 at 09:56, Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2018-07-05 01:31:00 | Re: Invisible Indexes |
| Previous Message | Larry Rosenman | 2018-07-05 01:19:48 | Re: peripatus build failures.... |