Re: Vacuum-full very slow

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
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 16:13:57
Message-ID: 20070425161357.GE7969@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Steve Crawford wrote:
> I'm in the process of archiving data on one of my PG machines. After
> backing up the data, I delete the old records and then run a "vacuum
> full" on each table.
>
> I'm vacuuming the first table now and it is taking much longer than I
> expected (I'm now past the 2-hour mark). Some info:
>
> Version: 8.1.2
> On-disk table size: ~1.9GB
> Records deleted from the table: 10,290,892 (~60% of records)
> Physical memory: 2GB
> Connection maintenance_work_mem: 1GB
> Table indexes: 7
> CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz
> Disk: 2x200GB SATA as RAID-1 using 3-ware card
>
> The vacuum full is the only significant load on the server at the moment
> (PG or otherwise). IO is probably the bottleneck as CPU is running near
> 50% idle and 40% wait-state with PG using in the 5-15% range.

You could try CLUSTER instead of VACUUM FULL, as I think it should be
faster. And the indexes will be devoid of any bloat, which will be a
nice side effect.

I wonder, though, if you set maintenance_work_mem too high and are
causing the OS to swap?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Manuel Sugawara 2007-04-25 16:15:09 Re: Audit-trail engine: getting the application's layer user_id
Previous Message A. Kretschmer 2007-04-25 15:56:41 Re: FOREIGN KEY CONSTRAINT AND INHERITANCE

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Wong 2007-04-25 16:26:10 Re: ECPG failure on BF member Vaquita (Windows Vista)
Previous Message Neil Conway 2007-04-25 15:58:21 Re: temporal variants of generate_series()