Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id AEFAF9FB3B2 for ; Thu, 26 Oct 2006 12:07:56 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 17224-10 for ; Thu, 26 Oct 2006 15:06:12 +0000 (UTC) X-Greylist: delayed 06:07:44.519864 by SQLgrey- Received: from pat.laterooms.com (fon.laterooms.com [194.24.251.1]) by postgresql.org (Postfix) with ESMTP id 094909FB33A for ; Thu, 26 Oct 2006 12:06:09 -0300 (ADT) Received: from pat.laterooms.com (localhost.localdomain [127.0.0.1]) by pat.laterooms.com (Postfix) with ESMTP id C2FA7C43A for ; Thu, 26 Oct 2006 16:06:07 +0100 (BST) Received: from teapot.laterooms.com (bum.net [194.24.251.10]) by pat.laterooms.com (Postfix) with SMTP id AF07FC14F for ; Thu, 26 Oct 2006 16:06:07 +0100 (BST) Date: Thu, 26 Oct 2006 16:06:09 +0100 From: Gavin Hamill To: pgsql-performance@postgresql.org Subject: Re: VACUUMs take twice as long across all nodes Message-Id: <20061026160609.5e94e581.gdh@laterooms.com> In-Reply-To: <20196.1161874041@sss.pgh.pa.us> References: <20061026095827.9e85e1c0.gdh@laterooms.com> <20196.1161874041@sss.pgh.pa.us> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.134 tagged_above=0 required=5 tests=FORGED_RCVD_HELO, SPF_PASS X-Spam-Level: X-Archive-Number: 200610/551 X-Sequence-Number: 21680 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. Cheers, Gavin.