Re[2]: Alter index rename concurrently to

From: Andrey Klychkov <aaklychkov(at)mail(dot)ru>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re[2]: Alter index rename concurrently to
Date: 2018-07-17 12:36:46
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> Понедельник, 16 июля 2018, 22:19 +03:00 от Andrey Borodin <x4mmm(at)yandex-team(dot)ru>:
>> 16 июля 2018 г., в 22:58, Andrey Klychkov < aaklychkov(at)mail(dot)ru > написал(а):
>> Dear hackers!
>> I have an idea to facilitate work with index rebuilding.
>> ....
>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()

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2018-07-17 13:01:36 Re: Pluggable Storage - Andres's take
Previous Message Fabien COELHO 2018-07-17 12:34:17 Re: Make foo=null a warning by default.