Re: VACCUM FULL ANALYZE PROBLEM - Mailing list pgsql-performance

From Tom Lane
Subject Re: VACCUM FULL ANALYZE PROBLEM
Date
Msg-id 8499.1108445430@sss.pgh.pa.us
Whole thread Raw
In response to Re: VACCUM FULL ANALYZE PROBLEM  ("Iain" <iain@mst.co.jp>)
Responses Re: VACCUM FULL ANALYZE PROBLEM
List pgsql-performance
"Iain" <iain@mst.co.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

pgsql-performance by date:

Previous
From: Rod Taylor
Date:
Subject: Re: seq scan cache vs. index cache smackdown
Next
From: Christopher Browne
Date:
Subject: Re: seq scan cache vs. index cache smackdown