On Wed, 2009-09-16 at 11:48 -0700, Josh Berkus wrote: > Hannu, > > > The only case is when you are out of disk space and can't afford to > > write out a full set of live rows. > > Well, it's actually rather specific. You need to have: > > a) *Some* free disk space (FULL requires extra disk) but not enough to > copy one entire table and its indexes. > > b) be already down or willing to accept the long downtime which comes > with FULL more than you're willing to go out and get some extra disk or > move your database to a new share. > > There's no question that this combination is fairly circumstantial and > represents a minority of potential vacuum cases. Unfortunately, it does > seem to represent some real-life ones, so we have to take those into > account.
Agreed. > > What I'd like to propose is VACUUM FULL CONCURRENTLY, which similar to > > VACUUM CONCURRENTLY, would actually do the compaction phase, that is, > > move simultaneously from two directions, from start, to find empty space > > and from end to find tuples. for each sufficiently large empty space the > > forward scan finds it would take one or more tuples from the reverse > > scan and then "null update" those to the empty space found by the > > free-space-scan beginning. it should do that in small chunks, say one > > page at a time, so it will minimally interfere with OLTP loads. > > How would this work with HS? Exactly the same as just doing a lot of UPDATE's which move tuples around between pages. It actually _is_ a lots of updates, just with extra condition that tuple is always moved to lowest available free slot. > -- > Josh Berkus > PostgreSQL Experts Inc. > www.pgexperts.com > -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers