> Понедельник, 16 июля 2018, 22:19 +03:00 от Andrey Borodin > <x4...@yandex-team.ru>: > >Hi! > >> 16 июля 2018 г., в 22:58, Andrey Klychkov < aaklych...@mail.ru > написал(а): >> Dear hackers! >> >> I have an idea to facilitate work with index rebuilding. >> .... >> "ALTER INDEX ... RENAME CONCURRENTLY TO ..." > >The idea seems useful. I'm not an expert in CIC, but your post do not cover >one very important topic. When we use CREATE INDEX CONCURRENTLY we pay for >less intrusive lock by scanning data twice. What is the price of RENAME >CONCURRENTLY? Should this mode be default? Hello and thank you for the answer!
I don't think "alter index ... rename concurrently to ..." has large overheads cause it just locks table and copies a new name instead of an old name to the field relform->relname of the FormData_pg_class struct. ./src/include/catalog/pg_class.h: typedef of FormData_pg_class ./src/backend/commands/tablecmds.c: RenameRelation() and RenameRelationInternal() As I wrote before, in my patch I've added the opportunity to change a locking AccessShareLock -> ShareUpdateExclusiveLock by passing "concurrently" in "alter", it's similar to the way of index_drop()/index_create() functions. It changes only one name field and nothing more. I believe it is safe. Also I ran tests again: select/insert queries in loops in several sessions and changed an index name concurrently in parallel many times. After that, index was valid and its index_scan was increased. However, I don't have much experience and maybe I am wrong. -- Kind regards, Andrey Klychkov
