Re: Feedback on getting rid of VACUUM FULL

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Feedback on getting rid of VACUUM FULL
Дата
Msg-id 603c8f070909161841m27f0f65av7711317a036382ef@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Feedback on getting rid of VACUUM FULL  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Feedback on getting rid of VACUUM FULL  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Feedback on getting rid of VACUUM FULL
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Feedback on getting rid of VACUUM FULL