vacuum full taking much longer than dump + restore? - Mailing list pgsql-general

From Dragan Matic
Subject vacuum full taking much longer than dump + restore?
Date
Msg-id 441E7AF2.2050202@panforma.co.yu
Whole thread Raw
Responses Re: vacuum full taking much longer than dump + restore?  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-general
We have a few larger tables (~3,5 million rows largest, ~ 1 million rows
smallest) on our production database which had at least one column
defined as char(nn) (nn being larger or equal to 60).
I did an alter table where I changed the definition of those columns to
varchar(nn), and after that did a 'UPDATE TABLE some_table SET
column_name = RTRIM(column_name)'.
Since it effectively doubled the number of rows I decided to do a vacuum
full. After some 10 hours I had to stop it since it was monday morning,
and vacuum was blocking the querys. After thad I did a pg_dump and a
restore and it was finished in about an hour and a half, with additional
15-20 minutes of vacuum analyze. I'm guessing that this
dump->restore->analyze has done effectively the same thing what vacuum
full was supposed to do. How is it possible that vacuum full was so
slow, are there some configuration parameters that might be
misconfigured? I am using fedora core 4 with pre-built 8.1.3 rpms.
Server has 2 gb of ram.

Tnx in advance

Dragan Matic


pgsql-general by date:

Previous
From: david.hoksza@seznam.cz
Date:
Subject: Re: ambuild parameters
Next
From: Guido Neitzer
Date:
Subject: Difference between "add column" and "add column" with default