Re: Block B-Tree concept

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Heikki Linnakangas <heikki(at)enterprisedb(dot)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