From: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
---|---|
To: | Sven Willenberger <sven(at)dmv(dot)com> |
Cc: | Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: VACUUM FULL versus CLUSTER ON |
Date: | 2006-07-07 16:00:27 |
Message-ID: | 1152288027.4948.5.camel@coppola.muc.ecircle.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
[snip]
> as I drop them prior to the huge delete, then create them anew). What
> would be the recommended method for reclaiming the disk space lost due
> to bloat? Dropping the 5 indexes on the table and doing a VACUUM FULL,
> keeping the indexes and doing a VACUUM FULL (does FULL perform the same
> disk moving operations on the indexes as it does on the actual table?),
> dropping the indexes except the primary key and CLUSTER ON primary key,
> keeping the indexes and doing a CLUSTER ON primary key (again, does
> CLUSTER ON just operation on the table proper?)
I won't know for sure, but I guess the least downtime you would get by
not dropping the indexes before the delete, but do a reindex after it.
Then cluster on the primary key...
My reasoning (correct me if I'm wrong): the deletion speed won't be
affected by the indexes, I think deletions don't touch the indexes at
all. The REINDEX command recreates all indexes at once, I think it needs
only one full table scan. That needs the indexes in place, so you
shouldn't drop them. The CLUSTER is a lot faster than VACUUM FULL. The
only problem could be that I think all these operations might take more
disk space than the individual indexing + VACUUM FULL.
Are my assumptions correct ?
Cheers,
Csaba.
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Broersma Jr | 2006-07-07 16:09:22 | Re: Long term database archival |
Previous Message | Tom Lane | 2006-07-07 15:54:26 | Re: Addressing: ERROR: could not access status of transaction |