Re: Feedback on getting rid of VACUUM FULL

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Feedback on getting rid of VACUUM FULL
Дата
Msg-id 1253202086.9666.188.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответ на Re: Feedback on getting rid of VACUUM FULL  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Feedback on getting rid of VACUUM FULL  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, 2009-09-17 at 11:25 -0400, Robert Haas wrote:
> On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Hannu Krosing <hannu@2ndQuadrant.com> writes:
> >> On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote:
> >>> VACUUM FULL CONCURRENTLY is a contradiction in terms.  Wishing it were
> >>> possible doesn't make it so.
> >
> >> It depends on what do you mean by "VACUUM FULL"
> >
> > Anything that moves tuples is not acceptable as a hidden background
> > operation, because it will break applications that depend on CTID.
> 
> I'm a bit confused.  CTIDs change all the time anyway, whenever you
> update the table.  What could someone possibly be using them for?

This part of the thread is somewhat strange. I don't think anybody was
suggesting the thing that Tom has assumed was meant, so how that chimera
would work isn't important. So, moving on...

The update utility being discussed is in danger of confusing these two
goals
* compact the table using minimal workspace
* compact the table with minimal interruption to concurrent updaters

We really *need* it to do the first for when emergencies arrive, but
most of the time we'd like it do the the second one. They aren't
necessarily the same thing and I don't want us to forget the "using
minimal workspace" requirement because the other one sounds so juicy.

-- Simon Riggs           www.2ndQuadrant.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Feedback on getting rid of VACUUM FULL
Следующее
От: Robert Fleming
Дата:
Сообщение: LDAP where DN does not include UID attribute