Re: Block B-Tree concept

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