Re: Feedback on getting rid of VACUUM FULL - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Feedback on getting rid of VACUUM FULL
Date
Msg-id 603c8f070909161841m27f0f65av7711317a036382ef@mail.gmail.com
Whole thread Raw
In response to Re: Feedback on getting rid of VACUUM FULL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Feedback on getting rid of VACUUM FULL
List pgsql-hackers
On Wed, Sep 16, 2009 at 9:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> The way I read the thread so far is that there are multiple
>> requirements:
>
>> * Shrink a table efficiently - when time and space available to do so
>
> To be addressed by the CLUSTER-based solution (VACUUM REWRITE or
> whatever we call it).
>
>> * Shrink a table in place - when no space available
>
> To be addressed by the UPDATE-style tuple-mover (which could be thought
> of as VACUUM FULL rewritten to not use any special mechanisms).
>
>> * Shrink a table concurrently - when no dedicated time available
>
> Wishful thinking, which should not stop us from proceeding with the
> solutions we know how to implement.

The UPDATE-style tuple-mover might work for this too, for certain
workloads.  If most of your transactions are short, and the server
load is not too high, it might be OK to lock the table, move a few
tuples, lock the table, move a few tuples, etc.  Now if you have
long-running transactions, not so much.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Feedback on getting rid of VACUUM FULL
Next
From: Tom Lane
Date:
Subject: Re: Feedback on getting rid of VACUUM FULL