On Wed, May 16, 2007 at 09:41:46AM +0200, Guillaume Cottenceau wrote: > Michael Stone <mstone+postgres 'at' mathom.us> writes: > > > On Tue, May 15, 2007 at 06:43:50PM +0200, Guillaume Cottenceau wrote: > > >patch - basically, I think the documentation under estimates (or > > >sometimes misses) the benefit of VACUUM FULL for scans, and the > > >needs of VACUUM FULL if the routine VACUUM hasn't been done > > >properly since the database was put in production. > > > > It's also possible to overestimate the benefit of vacuum full, leading > > to people vacuum full'ing almost constantly, then complaining about > > performance due to the associated overhead. I think there have been > > more people on this list whose performance problems were caused by > > unnecessary full vacs than by those whose performance problems were > > caused by insufficient full vacs. > > 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. Long term I think we should ditch 'VACUUM FULL' altogether and create a COMPACT command (it's very easy for users to get confused between "vacuum all the databases in the cluster" or "vacuum the entire database" and "VACUUM FULL"). -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
