Re: finding out vacuum completion %, and vacuum VS vacuum full - Mailing list pgsql-general

From Steve Atkins
Subject Re: finding out vacuum completion %, and vacuum VS vacuum full
Date
Msg-id 5C4F9434-0C2A-4E53-9488-862E8345830A@blighty.com
Whole thread Raw
In response to Re: finding out vacuum completion %, and vacuum VS vacuum full  (Sergei Shelukhin <realgeek@gmail.com>)
Responses Re: finding out vacuum completion %, and vacuum VS vacuum full  (Gregory Stark <stark@enterprisedb.com>)
Re: finding out vacuum completion %, and vacuum VS vacuum full  (Decibel! <decibel@decibel.org>)
Re: finding out vacuum completion %, and vacuum VS vacuum full  (Sergei Shelukhin <realgeek@gmail.com>)
List pgsql-general
On Aug 7, 2007, at 1:17 AM, Sergei Shelukhin wrote:

> Ok here's the update after ~30 hours we have killed vacuum full and
> did vacuum on the tables we freed.
> However, VACUUM hasn't freed any space at all 0_o
> We want to launch vacuum full on per-table basis but we can't have any
> more downtime right now so we will launch it at night today.
>
> The original question still stands, is there any way to diagnose
> vacuum full time-to-run?

It could easily take many days. VACUUM FULL is painfully slow.
Dropping indexes and suchlike can make it faster, but it's still
painfully slow.

> Or any way to optimize it besides the obvious (maintenace_work_mem &
> max_fsm_pages increases and no workload)?
> Can someone please help with this one?

VACUUM FULL is about the worst thing you can do in this case.

If you have adequate disk space free (enough to hold another
copy of the new table) and the table has an index on it, then
CLUSTER the table.

If not, dump and restore the table.

Cheers,
   Steve

pgsql-general by date:

Previous
From: "Gregory Williamson"
Date:
Subject: List tables in load order
Next
From: "Scott Marlowe"
Date:
Subject: Re: truncate transaction log