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.
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 |
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() |