| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Iain" <iain(at)mst(dot)co(dot)jp> |
| Cc: | "Michael Ryan S(dot) Puncia" <mpuncia(at)census(dot)gov(dot)ph>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: VACCUM FULL ANALYZE PROBLEM |
| Date: | 2005-02-15 05:30:30 |
| Message-ID: | 8499.1108445430@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Iain" <iain(at)mst(dot)co(dot)jp> writes:
>> another way to speed up full vacuum?
> Hmmm... a full vacuum may help to re-organize the structure of modified
> tables, but whether this is significant or not is another matter.
Actually, VACUUM FULL is designed to work nicely for the situation where
a table has say 10% wasted space and you want the wasted space all
compressed out. When there is a lot of wasted space, so that nearly all
the rows have to be moved to complete the compaction operation, VACUUM
FULL is not a very good choice. And it simply moves rows around, it
doesn't modify the rows internally; so it does nothing at all to reclaim
space that would have been freed up by DROP COLUMN operations.
CLUSTER is actually a better bet if you want to repack a table that's
suffered a lot of updates or deletions. In PG 8.0 you might also
consider one of the rewriting variants of ALTER TABLE.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Iain | 2005-02-15 05:58:16 | Re: VACCUM FULL ANALYZE PROBLEM |
| Previous Message | Christopher Browne | 2005-02-15 04:54:46 | Re: seq scan cache vs. index cache smackdown |