Re: Alter index rename concurrently to

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: Alter index rename concurrently to
Дата
Msg-id CADkLM=e9+x4GLdmSt1m7=vnv0mcFGUKcd2BgA26Zb0=yLUB0bQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Alter index rename concurrently to  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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.
 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: LLVM jit and matview
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [Proposal] Add accumulated statistics for wait event