Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id DBE019FB482 for ; Wed, 16 May 2007 04:41:53 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 80637-09 for ; Wed, 16 May 2007 04:41:47 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail.mnc.ch (62-2-77-205.static.cablecom.ch [62.2.77.205]) by postgresql.org (Postfix) with ESMTP id 289D79FB468 for ; Wed, 16 May 2007 04:41:50 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by mail.mnc.ch (Postfix) with ESMTP id 09EBCA82D6; Wed, 16 May 2007 09:41:48 +0200 (CEST) Received: from mail.mnc.ch ([127.0.0.1]) by localhost (mail.test.lan [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 27747-04; Wed, 16 May 2007 09:41:47 +0200 (CEST) Received: from meuh.mnc.lan (62-2-77-204.static.cablecom.ch [62.2.77.204]) by mail.mnc.ch (Postfix) with ESMTP id 0458EA82A5; Wed, 16 May 2007 09:41:47 +0200 (CEST) Received: by meuh.mnc.lan (Postfix, from userid 1000) id D18B5183679; Wed, 16 May 2007 09:41:46 +0200 (CEST) To: Michael Stone Cc: pgsql-performance@postgresql.org Subject: Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal References: <87lkfqavg9.fsf@meuh.mnc.lan> <20070515174427.GG1785@mathom.us> X-Hashcash: 1:20:070516:mstone@mathom.us::noDhaG/4RiApPj1z:08OCJ X-Hashcash: 1:20:070516:pgsql-performance@postgresql.org::8UQ09JAglVZ4JaTj:0000000000000000000000000000064Qw From: Guillaume Cottenceau Date: 16 May 2007 09:41:46 +0200 In-Reply-To: <20070515174427.GG1785@mathom.us> Message-ID: <87hcqdb4g5.fsf@meuh.mnc.lan> Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: amavisd-new at mnc.ch X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/283 X-Sequence-Number: 24673 Michael Stone 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? -- Guillaume Cottenceau, MNC Mobile News Channel SA, an Alcatel-Lucent Company Av. de la Gare 10, 1003 Lausanne, Switzerland - direct +41 21 317 50 36