X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id AF5C0D7EE6 for ; Tue, 30 Aug 2005 18:13:59 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 66555-09 for ; Tue, 30 Aug 2005 21:13:56 +0000 (GMT) Received: from web31606.mail.mud.yahoo.com (web31606.mail.mud.yahoo.com [68.142.198.152]) by svr1.postgresql.org (Postfix) with SMTP id 4E111D7DD2 for ; Tue, 30 Aug 2005 18:13:54 -0300 (ADT) Received: (qmail 48140 invoked by uid 60001); 30 Aug 2005 21:13:56 -0000 Message-ID: <20050830211356.48138.qmail@web31606.mail.mud.yahoo.com> Received: from [209.217.70.195] by web31606.mail.mud.yahoo.com via HTTP; Tue, 30 Aug 2005 14:13:55 PDT Date: Tue, 30 Aug 2005 14:13:55 -0700 (PDT) From: Markus Benne Reply-To: markus@m-bass.com Subject: When to do a vacuum for highly active table To: pgsql-performance@postgresql.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 required=5 tests=[none] X-Spam-Level: X-Archive-Number: 200508/541 X-Sequence-Number: 14288 We have a highly active table that has virtually all entries updated every 5 minutes. Typical size of the table is 50,000 entries, and entries have grown fat. We are currently vaccuming hourly, and towards the end of the hour we are seeing degradation, when compared to the top of the hour. Vaccum is slowly killing our system, as it is starting to take up to 10 minutes, and load at the time of vacuum is 6+ on a Linux box. During the vacuum, overall system is goin unresponsive, then comes back once vacuum completes. If we run vacuum less frequently, degradation continues to the point that we can't keep up with the throughput, plus vacuum takes longer anyway. Becoming quite a pickle:-) We are thinking of splitting the table in two: the part the updates often, and the part the updates infrequently as we suspect that record size impacts vacuum. Any ideas? Thanks, Mark -----------------