On Wed, May 16, 2007 at 12:09:26PM -0400, Alvaro Herrera wrote: > Guillaume Cottenceau wrote: > > "Jim C. Nasby" <decibel 'at' decibel.org> writes: > > > > > On Wed, May 16, 2007 at 09:41:46AM +0200, Guillaume Cottenceau wrote: > > > > [...] > > > > > > Come on, I don't suggest to remove several bold warnings about > > > > it, the best one being "Therefore, frequently using VACUUM FULL > > > > can have an extremely negative effect on the performance of > > > > concurrent database queries." My point is to add the few > > > > additional mentions; I don't think the claims that VACUUM FULL > > > > physically compacts the data, and might be useful in case of too > > > > long time with infrequent VACUUM are incorrect, are they? > > > > > > Unfortunately they are, to a degree. VACUUM FULL can create a > > > substantial amount of churn in the indexes, resulting in bloated > > > indexes. So often you have to REINDEX after you VACUUM FULL. > > > > Ok, VACUUM FULL does his job (it physically compacts the data and > > might be useful in case of too long time with infrequent VACUUM), > > but we are going to not talk about it because we often needs a > > REINDEX after it? The natural conclusion would rather be to > > document the fact than REINDEX is needed after VACUUM FULL, isn't > > it? > > Maybe, but we should also mention that CLUSTER is a likely faster > workaround.
What this boils down to is that there should probably be a separate subsection that deals with "Oh noes! My tables are too big!" -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings