Re: Support for REINDEX CONCURRENTLY - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support for REINDEX CONCURRENTLY
Date
Msg-id CAB7nPqQaVNDqZkzGOWRDWJ9G5udfZ2z8cAZ_QU2EVUhxbWtRsQ@mail.gmail.com
Whole thread Raw
In response to Re: Support for REINDEX CONCURRENTLY  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Support for REINDEX CONCURRENTLY  (Fujii Masao <masao.fujii@gmail.com>)
Re: Support for REINDEX CONCURRENTLY  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
I have been working on improving the code of the 2 patches:
1) reltoastidxid removal:
- Improvement of mechanism in tuptoaster.c to fetch the first valid index for toast value deletion and fetch
- Added a macro called RelationGetIndexListIfValid that avoids recompiling the index list with list_copy as RelationGetIndexList does. Not using a macro resulted in increased shared memory usage when multiple toast values were added inside the same query (stuff like "insert into tab values (generate_series(1,1000), '2k_long_text')")
- Fix a bug with pg_dump and binary upgrade. One valid index is necessary for a given toast relation.
2) reindex concurrently:
- correction of some comments
- fix for index_concurrent_set_dead where process did not wait that other backends released lock on parent relation
- addition of a error message in index_concurrent_drop if it is tried to drop a live index. Dropping a live index with only ShareUpdate lock is  dangerous

I am also planning to test the potential performance impact of the patch removing reltoastidxid with scripts of the type attached. I don't really know if it can be quantified but I'll give a try with some methods (not yet completely defined).
--
Michael
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Request for vote to move forward with recovery.conf overhaul
Next
From: Robert Haas
Date:
Subject: Re: Duplicate JSON Object Keys