Re: VACUUM FULL memory requirements

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
Cc: "David Schnur" <dnschnur(at)gmail(dot)com>,<pgsql-admin(at)postgresql(dot)org>
Subject: Re: VACUUM FULL memory requirements
Date: 2009-12-14 21:54:57
Message-ID: 4B265FD1020000250002D4A1@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Scott Marlowe <scott(dot)marlowe(at)gmail(dot)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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Evan Rempel 2009-12-14 23:04:47 Internal fragmentations statistics Was: VACUUM FULL memory requirements
Previous Message Scott Marlowe 2009-12-14 21:20:30 Re: VACUUM FULL memory requirements