From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | peter(dot)eisentraut(at)2ndquadrant(dot)com |
Cc: | aaklychkov(at)mail(dot)ru, pgsql-hackers(at)postgresql(dot)org, vyegorov(at)gmail(dot)com |
Subject: | Re: Alter index rename concurrently to |
Date: | 2018-07-25 23:58:12 |
Message-ID: | CADkLM=e9+x4GLdmSt1m7=vnv0mcFGUKcd2BgA26Zb0=yLUB0bQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> You appear to be saying that you think that renaming an index
> concurrently is not safe. In that case, this patch should be rejected.
> However, I don't think it necessarily is unsafe. What we need is some
> reasoning about the impact, not a bunch of different options that we
> don't understand.
>
I've had this same need, and dreamed this same solution before. I also
thought about a syntax like ALTER INDEX foo RENAME TO
WHATEVER-IT-WOULD-HAVE-BEEN-NAMED-BY-DEFAULT to aid this situation.
But all of those needs fade if we have REINDEX CONCURRENTLY. I think that's
where we should focus our efforts.
A possible side effort into something like a VACUUM FULL CONCURRENTLY,
which would essentially do what pg_repack does, but keeping the same oid
and the stats that go with it, but even that's a nice-to-have add-on to
REINDEX CONCURRENTLY.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-07-26 01:24:51 | Re: [Proposal] Add accumulated statistics for wait event |
Previous Message | Andres Freund | 2018-07-25 23:48:26 | Re: LLVM jit and matview |