Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-admin by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group