Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 441F8632FBA for ; Sat, 27 Mar 2010 10:41:07 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 78467-08 for ; Sat, 27 Mar 2010 13:40:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from 26.mail-out.ovh.net (26.mail-out.ovh.net [91.121.27.225]) by mail.postgresql.org (Postfix) with SMTP id 6788E632F32 for ; Sat, 27 Mar 2010 10:40:56 -0300 (ADT) Received: (qmail 21049 invoked by uid 503); 27 Mar 2010 13:47:32 -0000 Received: from b6.ovh.net (HELO mail620.ha.ovh.net) (213.186.33.56) by 26.mail-out.ovh.net with SMTP; 27 Mar 2010 13:47:32 -0000 Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 27 Mar 2010 13:41:39 -0000 Received: from par69-8-88-161-102-87.fbx.proxad.net (HELO immo.peufeu.com) (lists%peufeu.com@88.161.102.87) by ns0.ovh.net with SMTP; 27 Mar 2010 13:41:37 -0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: gnanam@zoniac.com, pgsql-performance@postgresql.org Subject: Re: Database size growing over time and leads to performance impact References: <004701cacdad$7013e9f0$503bbdd0$@com> Date: Sat, 27 Mar 2010 14:35:15 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Pierre C" Message-ID: In-Reply-To: <004701cacdad$7013e9f0$503bbdd0$@com> User-Agent: Opera Mail/10.10 (Linux) X-Ovh-Tracer-Id: 797418609918871044 X-Ovh-Remote: 88.161.102.87 (par69-8-88-161-102-87.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.5/N X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=-10 required=5 tests=BAYES_50=0.001 X-Spam-Level: X-Archive-Number: 201003/346 X-Sequence-Number: 38171 > 1. VACUUM FULL ANALYZE once in a week during low-usage time and VACUUM FULL compacts tables, but tends to bloat indexes. Running it weekly is NOT RECOMMENDED. A correctly configured autovacuum (or manual vacuum in some circumstances) should maintain your DB healthy and you shouldn't need VACUUM FULL. If you realize you got a bloat problem, for instance due to a misconfigured vacuum, use CLUSTER, which re-generates table AND index data, and besides, having your table clustered on an index of your choice can boost performance quite a lot in some circumstances. 8.2 is so old I don't remember if autovacuum is even included. Please try upgrading to the latest version... Since your database probably fits in RAM, CLUSTER will be pretty fast. You can schedule it weekly, if you need clustering. If you don't, autovacuum will suffice. Hint : add a "SELECT count(*) FROM yourtable;" before "CLUSTER yourtable;" so that the table is pulled in the OS disk cache, it'll make CLUSTER faster.