| 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: | Whole Thread | Raw Message | 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 |