Re: Vacuum-full very slow

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Vacuum-full very slow
Date: 2007-04-25 17:38:46
Message-ID: 20070425173846.GB15706@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Wed, Apr 25, 2007 at 09:36:35AM -0700, Steve Crawford wrote:
> Hmmm, why would cluster be faster?

Basically, vacuum full moves tuples from the end to the beginning of a
table so it can compact the table. In the process it needs to update
all the indexes too. So you save heap space but it tends to fragment
your index. Lots of disk writes also.

OTOH, cluster simply scans the table, sorts it, writes it out then
rebuilds the indexes. If you've removed a lot of tuples, empirically
it's faster.

VACUUM FULL is discouraged these days, simply becuase it isn't actually
as efficient as you might expect. Better to make sure it doesn't grow
big in the first place, and use CLUSTER to rebuild the table if you
really need to.

Hope this helps,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message araza 2007-04-25 18:02:39 Where to find kind code for STATISTIC_KIND GEOMETRY?
Previous Message Marcelo de Moraes Serpa 2007-04-25 17:36:32 Re: Audit-trail engine: getting the application's layer user_id

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-04-25 18:02:22 Re: ECPG failure on BF member Vaquita (Windows Vista)
Previous Message Tom Lane 2007-04-25 17:20:13 Re: Avoiding unnecessary reads in recovery