Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 9B1892E2EF5 for ; Fri, 7 Mar 2008 10:35:48 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 93598-02-3 for ; Fri, 7 Mar 2008 10:35:38 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by postgresql.org (Postfix) with ESMTP id D286A2E3136 for ; Fri, 7 Mar 2008 10:34:54 -0400 (AST) Received: from vanquish.ws.pitbpa0.priv.collaborativefusion.com (vanquish.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.162]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Fri, 07 Mar 2008 09:34:53 -0500 id 00056420.47D1528D.00015FDA Date: Fri, 7 Mar 2008 09:34:53 -0500 From: Bill Moran To: "Pavel Rotek" Cc: pgsql-performance@postgresql.org Subject: Re: Toast space grows Message-Id: <20080307093453.110cff74.wmoran@collaborativefusion.com> In-Reply-To: <3556c08c0803070611p542eb317vfaf9b783172b6c3@mail.gmail.com> References: <3556c08c0803070035p6d8b4aa8m6318f54728f61022@mail.gmail.com> <47D10722.4080508@archonet.com> <3556c08c0803070129y6ffabf32i1c8bae445ec460e0@mail.gmail.com> <20080307065314.1248665b.wmoran@collaborativefusion.com> <3556c08c0803070459i8598423t64e0704e48af533@mail.gmail.com> <11848.1204896799@sss.pgh.pa.us> <3556c08c0803070611p542eb317vfaf9b783172b6c3@mail.gmail.com> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.8; i386-portbld-freebsd6.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/166 X-Sequence-Number: 29120 In response to "Pavel Rotek" : > 2008/3/7, Tom Lane : [snip] > > If you have to do it that way, you'll need very frequent vacuums on this > > table (not vacuum full, as noted already) to keep the toast space from > > bloating too much. And make sure you've got max_fsm_pages set high > > enough. > > i'll set max_fsm_pages to 1 000 000. It should be enough and set > autovacuum_naptime to 10 minutes. May it be? No. Keep naptime at 1 minute. If it comes around and there's nothing to do, the overhead is minimal. If you set the naptime too high, it might have too much to do on the next cycle and then it'll bog things down. Also, it only checks 1 database per cycle, so setting it to 10 minutes means a _minimum_ of 40 minutes between checks (because you have a template0, template1, postgres, and your database minimum) Also, keep an eye on your database bloat to ensure the various autovacuum_*_scale_factor and related settings are appropriate. It's been found that these are often not aggressive enough for good maintenance. If you see bloat even with autovacuum running, reduce those values. Personally, I'd recommend running a MRTG graph that graphs the size of this table so you can easily watch to see if your config tweaks are getting the job done or not. And remember that _some_ bloat is expected and normal for operation. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023