Re: Bug in VACUUM FULL ?

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Bug in VACUUM FULL ?
Дата
Msg-id 1173479249.3641.383.camel@silverbirch.site
обсуждение исходный текст
Ответ на Re: Bug in VACUUM FULL ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Bug in VACUUM FULL ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Bug in VACUUM FULL ?  ("Joshua D. Drake" <jd@commandprompt.com>)
Список pgsql-hackers
On Fri, 2007-03-09 at 16:40 -0500, Tom Lane wrote:
> I wonder whether this has any implications for HOT ...

My general feeling, expressed in a number of recent posts was that the
VACUUM FULL code really isn't worth the trouble it causes. Especially
when CLUSTER does a better job anyway?

I've proposed a number of different proposals for changing VACUUM FULL,
and Hannu posted some really cool ideas.

Please can we spend time doing something useful, rather than trying to
fix up a bag of worms that nobody ever runs? C'mon guys, this isn't a
challenge, its a lost cause. I don't really mean to be radical, but I
just think VACUUM FULL's time has come. A better utility could be
written in the time it takes to fix and be certain of a fix.

Yes, we need a utility that compacts a table, but isn't there a faster,
safer way of doing that than the current VACUUM FULL algorithm and code?
We can still *call* it VACUUM FULL. Modular replacement has been done
numerous times over the years with great success, e.g. tuplesort, index
build... lets do the same thing now and kiss goodbye to some code whose
time has come. 

Put it another way: if anybody submitted a patch that does what VACUUM
FULL does, coded in the way it is, it would never be applied, now.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com




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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: who gets paid for this
Следующее
От: Alvaro Herrera
Дата:
Сообщение: autovacuum next steps, take 3