Re: Bug in VACUUM FULL ? - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Bug in VACUUM FULL ?
Date
Msg-id 1173479249.3641.383.camel@silverbirch.site
Whole thread Raw
In response to Re: Bug in VACUUM FULL ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bug in VACUUM FULL ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Bug in VACUUM FULL ?  ("Joshua D. Drake" <jd@commandprompt.com>)
List 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 by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: who gets paid for this
Next
From: Alvaro Herrera
Date:
Subject: autovacuum next steps, take 3