Re: VACUUM FULL memory requirements - Mailing list pgsql-admin

From Kevin Grittner
Subject Re: VACUUM FULL memory requirements
Date
Msg-id 4B265FD1020000250002D4A1@gw.wicourts.gov
Whole thread Raw
In response to Re: VACUUM FULL memory requirements  (Scott Marlowe <scott.marlowe@gmail.com>)
Responses Re: VACUUM FULL memory requirements  (David Schnur <dnschnur@gmail.com>)
List pgsql-admin
Scott Marlowe <scott.marlowe@gmail.com> wrote:

> My usage is dictated by using slony, which means I can't do the
> things I'd like, like just copying the data out of the table,
> truncating it, and copying it back in / renaming the newly created
> table as the old one etc.  So for me, and other slony users who
> can't do the wild westish stuff we'd otherwise resort to, vacuum
> full is very useful in some circumstances.  So, an improved vacuum
> full would be much appreciated.  The proposed replacement, would
> it still be able to recover lost space like the old one?

As I understand it (with some confidence that others will correct
any errors), the default behavior of VACUUM FULL in the new
arrangement will be to copy the table -- similar to CLUSTER but
without using an index.  The thing still up in the air is whether to
support the old style VACUUM FULL behavior as an INPLACE option.  In
any event, there will probably be a utility to move tuples from the
end of the table to free space, which will allow a normal VACUUM to
free the space to the OS.  This utility is proposed as a client app,
which you will need to schedule on your own as needed.

-Kevin

pgsql-admin by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: VACUUM FULL memory requirements
Next
From: Evan Rempel
Date:
Subject: Internal fragmentations statistics Was: VACUUM FULL memory requirements