>Понедельник, 16 июля 2018, 22:40 +03:00 от Victor Yegorov <vyego...@gmail.com>:
>
>пн, 16 июл. 2018 г. в 21:58, Andrey Klychkov < aaklych...@mail.ru >:
>>I made a patch to solve this issue (see the attachment).
>>It allows to avoid locks by a query like this:
>>“alter index <new_index> rename CONCURRENTLY to <old_index_name>”.
>
>Please, have a look at previous discussions on the subject:
>- 2012
>https://www.postgresql.org/message-id/cab7npqtys6juqdxuczbjb0bnw0kprw8wdzuk11kaxqq6o98...@mail.gmail.com
>- 2013
>https://www.postgresql.org/message-id/cab7npqstfkuc7dzxcdx4hotu63yxhrronv2aouzyd-zz_8z...@mail.gmail.com
>- https://commitfest.postgresql.org/16/1276/
>
Hello,
Thank you for this information!
In the first discussion the concurrent alter was mentioned.
In the next link and commitfest info I only saw "Reindex concurrently 2.0".
It sounds great!
If this component will be added to core it certainly facilitates index
rebuilding.
What about "alter index ... rename to" in the concurrent mode?
Does "Reindex concurrently 2.0" add it?
From time to time we need just to rename some indexes.
Without concurrent mode this "alter index" makes queues.
It may be a problem on high load databases.
--
Kind regards,
Andrey Klychkov
