Re: Alter index rename concurrently to

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.

In response to

Browse pgsql-hackers by date

  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