Re: Feedback on getting rid of VACUUM FULL

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Feedback on getting rid of VACUUM FULL
Date: 2009-09-17 01:41:13
Message-ID: 603c8f070909161841m27f0f65av7711317a036382ef@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 16, 2009 at 9:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-09-17 01:48:20 Re: Feedback on getting rid of VACUUM FULL
Previous Message Tom Lane 2009-09-17 01:35:25 Re: Feedback on getting rid of VACUUM FULL