Tom Lane <[EMAIL PROTECTED]> writes: > Heikki Linnakangas <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings