Re: REINDEX on large DB vs. DROP INDEX/CREATE INDEX

Just a follow-up on this... The REINDEX took about 2 1/2 days. I didn't
gain much disk space back - a full backup takes just as long as before, but
the vacuum time dropped from 30 hours to 3 hours.

Wes

>> 1. Is there any advantage to doing the DROP/CREATE over just doing a REINDEX
>> DATABASE.
>
> No, not if you don't mind exclusive locks. DROP together with CREATE
> INDEX CONCURRENTLY might be nicer if you were trying to do this without
> completely shutting down the DB, but if you aren't running normal
> operations then just use REINDEX.
>
>> 2. I'm assuming REINDEX would avoid the time involved in recreating the
>> foreign key constraints?
>
> Right, that's one reason to do it that way.