Re: Eliminating VACUUM FULL WAS: remove flatfiles.c

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Eliminating VACUUM FULL WAS: remove flatfiles.c
Дата
Msg-id 24852.1252114654@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Eliminating VACUUM FULL WAS: remove flatfiles.c  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Eliminating VACUUM FULL WAS: remove flatfiles.c  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Sep 4, 2009 at 4:01 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> Hmm ... reading that over again, it seems like there is a pretty
>> obvious solution.

> This doesn't seem totally horrible.  But, before you go do it, do we
> have a clearly-defined plan for the rest of the project?

Rest of what project?  Removing vacuum full isn't a necessary component
of that.  It would enable doing CLUSTER on pg_class, and it would
eliminate the crock of REINDEX having to reindex shared indexes
in-place.  It could probably be justified even without any changes in
our approach to vacuum.

> ... only need this if we're absolutely confident that rewriting the table
> in place is just not an option worth keeping around.  It's unclear to
> me that everyone is convinced of that, and even if they are, it's
> unclear to me what we plan to implement instead.

I thought we were pretty well agreed that a seqscan variant of
CLUSTER would be worth doing.  Whether we take the next step by
eliminating vacuum full is a different question, but the shape of
the substitute seems perfectly clear.
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Eliminating VACUUM FULL WAS: remove flatfiles.c
Следующее
От: Tom Lane
Дата:
Сообщение: Re: match_unsorted_outer() vs. cost_nestloop()