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 92617D86A7 for ; Tue, 30 Aug 2005 20:04:08 -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 94807-07 for ; Tue, 30 Aug 2005 23:04:05 +0000 (GMT) Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.116.145.2]) by svr1.postgresql.org (Postfix) with ESMTP id 07736D8691 for ; Tue, 30 Aug 2005 20:04:04 -0300 (ADT) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id CC26430956; Wed, 31 Aug 2005 01:04:03 +0200 (MET DST) From: Chris Browne X-Newsgroups: pgsql.performance Subject: Re: When to do a vacuum for highly active table Date: Tue, 30 Aug 2005 18:05:38 -0400 Organization: cbbrowne Computing Inc Lines: 33 Message-ID: <6064tn6pxp.fsf@dba2.int.libertyrms.com> References: <20050830211356.48138.qmail@web31606.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Complaints-To: usenet@news.hub.org User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (Jumbo Shrimp, linux) Cancel-Lock: sha1:Mb6tP0jYqjMBqYOk/ujn4/x8Npg= To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.101 required=5 tests=[AWL=0.101] X-Spam-Level: X-Archive-Number: 200508/548 X-Sequence-Number: 14295 thing@m-bass.com (Markus Benne) writes: > 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. You're not vacuuming the table nearly often enough. You should vacuum this table every five minutes, and possibly more often than that. [We have some tables like that, albeit smaller than 50K entries, which we vacuum once per minute in production...] > 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. There's *some* merit to that. You might discover that there's a "hot spot" that needs to be vacuumed once per minute. But it may be simpler to just hit the table with a vacuum once every few minutes even though some tuples are seldom updated. -- output = reverse("gro.gultn" "@" "enworbbc") http://cbbrowne.com/info/spreadsheets.html Signs of a Klingon Programmer #3: "By filing this TPR you have challenged the honor of my family. Prepare to die!"