Skip site navigation (1) Skip section navigation (2)

Re: VACCUM FULL ANALYZE PROBLEM

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 (view raw or flat)
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

In response to

Responses

pgsql-performance by date

Next:From: IainDate: 2005-02-15 05:58:16
Subject: Re: VACCUM FULL ANALYZE PROBLEM
Previous:From: Christopher BrowneDate: 2005-02-15 04:54:46
Subject: Re: seq scan cache vs. index cache smackdown

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group