Tom Lane <tgl@sss.pgh.pa.us> writes:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> Also, now that we have concurrent CREATE INDEX, we could implement
>> concurrent REINDEX as well, I believe.
>
> That's probably more easily said than done --- in particular, I don't
> understand what the committed state after the first transaction would
> look like. CREATE INDEX can get away with it because nothing need be
> depending on the new index, but you can't say that for an existing index
> (esp. if it's UNIQUE).
I think you build a whole new index named something like ".temp-reindex" and
then as the last step of the second transaction delete the old idnex and
rename the new index.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com