Re: Support for REINDEX CONCURRENTLY

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Support for REINDEX CONCURRENTLY
Date: 2013-03-13 12:04:48
Message-ID: CAB7nPqQaVNDqZkzGOWRDWJ9G5udfZ2z8cAZ_QU2EVUhxbWtRsQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
20130313_1_remove_reltoastidxid_v6.patch application/octet-stream 43.0 KB
20130313_2_reindex_concurrently_v24.patch application/octet-stream 81.9 KB
toast_long.bash application/octet-stream 274 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-03-13 12:17:13 Re: Duplicate JSON Object Keys
Previous Message Michael Paquier 2013-03-13 11:50:54 Re: Request for vote to move forward with recovery.conf overhaul