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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
