Re: How overcome wait for vacuum full? - Mailing list pgsql-admin

From Geoff Tolley
Subject Re: How overcome wait for vacuum full?
Date
Msg-id 464A3E24.6060204@polimetrix.com
Whole thread Raw
In response to How overcome wait for vacuum full?  (Nick Urbanik <nicku@nicku.org>)
Responses Re: How overcome wait for vacuum full?  (Nick Urbanik <nicku@nicku.org>)
List pgsql-admin
Nick Urbanik wrote:

> I am running a full vacuum on a database.  It's taking longer than I
> hoped.  In particular, the vacuum still hasn't reached the table that
> will benefit most from the vacuum.
>
> Can I move the existing table to a backup, make a copy of the table
> back to its original name, restart the application, and run the vacuum
> on the backup?  Or can I reclaim the disk space by dropping the
> original after making a copy?
>
> If I can, without losing data, what is the best way to do that?
> I am reaching the end of the period when this database application can
> be disabled.

If you're waiting on vacuum to get around to the one table, you can run
VACUUM FULL <tablename> instead.

Personally I've found that dropping indices (including the PK), then vacuum
full, then recreating indices can be an awful lot faster than just leaving
vacuum full to its own devices.

Yes you ought to be able to reclaim disk space by the copy/drop
original/rename procedure, but that gets hard to manage if you have
triggers or foreign keys on the table in question. You might want to use
CREATE TABLE table_copy (LIKE orig_table) to preserve column defaults if
you go down that path.

HTH,
Geoff

pgsql-admin by date:

Previous
From: Steve Holdoway
Date:
Subject: improve select performance...
Next
From: Nick Urbanik
Date:
Subject: Re: How overcome wait for vacuum full?