Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id CC09C9FA38F for ; Thu, 26 Oct 2006 16:17:42 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 05654-05 for ; Thu, 26 Oct 2006 16:17:32 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 7C5349FA3A3 for ; Thu, 26 Oct 2006 16:17:32 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 6354F5643A; Thu, 26 Oct 2006 14:17:31 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Thu, 26 Oct 2006 14:17:29 -0500 Date: Thu, 26 Oct 2006 14:17:29 -0500 From: "Jim C. Nasby" To: Gavin Hamill Cc: pgsql-performance@postgresql.org Subject: Re: VACUUMs take twice as long across all nodes Message-ID: <20061026191728.GD26892@nasby.net> References: <20061026095827.9e85e1c0.gdh@laterooms.com> <20196.1161874041@sss.pgh.pa.us> <20061026160609.5e94e581.gdh@laterooms.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061026160609.5e94e581.gdh@laterooms.com> X-Operating-System: FreeBSD 6.1-RELEASE-p10 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.13 (2006-08-11) X-Hashcash: 1:20:061026:gdh@laterooms.com::ctUExW3dfHWKM2Xt:00000000000000000000 0000000000000000000000003Kt4 X-Hashcash: 1:20:061026:pgsql-performance@postgresql.org::IpK43W4BHbs1PbHZ:00000 0000000000000000000000002D/U X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.079 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200610/561 X-Sequence-Number: 21690 On Thu, Oct 26, 2006 at 04:06:09PM +0100, Gavin Hamill wrote: > On Thu, 26 Oct 2006 10:47:21 -0400 > Tom Lane wrote: > > > Gavin Hamill writes: > > > Nodes 2 and 3 take only the tables necessary to run our search (10 > > > out of the full 130) and are much lighter (only 7GB on disk cf. > > > 30GB for the full master) , yet the nightly VACUUM FULL has jumped > > > from 2 hours to 4 in the space of one day! > > > > I guess the most useful question to ask is "why are you doing VACUUM > > FULL?" Plain VACUUM should be considerably faster, and for the level > > of row turnover shown by your log, there doesn't seem to be a reason > > to use FULL. > > I do FULL on the 'light' clients simply because 'I can'. The example > posted was a poor choice - the other tables have a larger churn. > > Anyway, once it starts, the load balancer takes it out of rotation so > no love is lost. > > The same behaviour is shown on the 'heavy' clients (master + 2 slaves) > which take all tables - although I cannot afford to VACUUM FULL on > there, the usual VACUUM ANALYZE has begun to take vastly more time > since yesterday than in the many previous months we've been using pg. Are you sure that there's nothing else happening on the machine that could affect the vacuum times? Like, say a backup? Or perhaps updates coming in from Slony that didn't used to be there? -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)