Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id D95779FB400 for ; Tue, 19 Jun 2007 10:46:31 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 30526-06 for ; Tue, 19 Jun 2007 10:46:21 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from oxford.xeocode.com (unknown [62.232.55.118]) by postgresql.org (Postfix) with ESMTP id 13CA59FB3DB for ; Tue, 19 Jun 2007 10:46:27 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=oxford.xeocode.com) by oxford.xeocode.com with esmtp (Exim 4.67) (envelope-from ) id 1I0e2E-0003jZ-G3; Tue, 19 Jun 2007 14:46:18 +0100 From: Gregory Stark To: "Karl Wright" Cc: "Tom Lane" , Subject: Re: Performance query about large tables, lots of concurrent access In-Reply-To: <4677D298.2010109@metacarta.com> (Karl Wright's message of "Tue, 19 Jun 2007 08:56:56 -0400") Organization: EnterpriseDB References: <4676DD57.7070304@metacarta.com> <14291.1182221811@sss.pgh.pa.us> <4677B831.8060704@metacarta.com> <4677D298.2010109@metacarta.com> X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX.performance" 1072) Date: Tue, 19 Jun 2007 14:46:18 +0100 Message-ID: <87bqfc83bp.fsf@oxford.xeocode.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200706/336 X-Sequence-Number: 25369 "Karl Wright" writes: > This particular run lasted four days before a VACUUM became essential. The > symptom that indicates that VACUUM is needed seems to be that the CPU usage of > any given postgresql query skyrockets. Is this essentially correct? Postgres is designed on the assumption that VACUUM is run regularly. By "regularly" we're talking of an interval usually on the order of hours, or even less. On some workloads some tables need to be vacuumed every 5 minutes, for example. VACUUM doesn't require shutting down the system, it doesn't lock any tables or otherwise prevent other jobs from making progress. It does add extra i/o but there are knobs to throttle its i/o needs. The intention is that VACUUM run in the background more or less continually using spare i/o bandwidth. The symptom of not having run vacuum regularly is that tables and indexes bloat to larger sizes than necessary. If you run "VACUUM VERBOSE" it'll tell you how much bloat your tables and indexes are suffering from (though the output is a bit hard to interpret). Table and index bloat slow things down but not generally by increasing cpu usage. Usually they slow things down by causing queries to require more i/o. It's only UPDATES and DELETES that create garbage tuples that need to be vacuumed though. If some of your tables are mostly insert-only they might need to be vacuumed as frequently or at all. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com