Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id DBA7865008C for ; Wed, 30 Jul 2008 12:05:23 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 94404-05 for ; Wed, 30 Jul 2008 12:05:20 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 61B5564FFC0 for ; Wed, 30 Jul 2008 12:05:20 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m6UF5G3Y025538; Wed, 30 Jul 2008 11:05:16 -0400 (EDT) To: "Dave North" cc: "Richard Huxton" , pgsql-performance@postgresql.org Subject: Re: Database size Vs performance degradation In-reply-to: <35FABCF85D99464FB00BC5123DC2A70A051D0FEC@s228130hz1ew09.apptix-01.savvis.net> References: <35FABCF85D99464FB00BC5123DC2A70A051D0FB8@s228130hz1ew09.apptix-01.savvis.net> <48905E59.9040007@archonet.com> <35FABCF85D99464FB00BC5123DC2A70A051D0FEC@s228130hz1ew09.apptix-01.savvis.net> Comments: In-reply-to "Dave North" message dated "Wed, 30 Jul 2008 07:41:25 -0500" Date: Wed, 30 Jul 2008 11:05:16 -0400 Message-ID: <25537.1217430316@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200807/246 X-Sequence-Number: 30846 "Dave North" writes: > From: Richard Huxton [mailto:dev@archonet.com] >> Well, that's pretty much the definition of bloat. Are you sure you're >> vacuuming enough? > DN: Well, the auto-vac is kicking off pretty darn frequently...around > once every 2 minutes. However, you just made me think of the obvious - > is it actually doing anything?! The app is pretty darn write intensive > so I wonder if it's actually able to vacuum the tables? IIRC, the default autovac parameters in 8.1 were pretty darn unaggressive. You should also check for long-running transactions that might be preventing vacuum from removing recently-dead rows. One of the reasons for updating off 8.1 is that finding out what autovac is really doing is hard :-(. I think it does log, but at level DEBUG2 or so, which means that the only way to find out is to accept a huge amount of useless chatter in the postmaster log. Newer releases have a saner logging scheme. regards, tom lane