X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 7CB6E9DCA1C for ; Mon, 27 Feb 2006 13:26:06 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 58769-07 for ; Mon, 27 Feb 2006 13:26:05 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id 006AF9DC8A5 for ; Mon, 27 Feb 2006 13:26:03 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 8CF2C30C21; Mon, 27 Feb 2006 18:26:03 +0100 (MET) From: Chris Browne X-Newsgroups: pgsql.performance Subject: Re: Large Table With Only a Few Rows Date: Mon, 27 Feb 2006 12:25:26 -0500 Organization: cbbrowne Computing Inc Lines: 36 Message-ID: <60slq4zpbt.fsf@dba2.int.libertyrms.com> References: <1141051682.534005.194130@v46g2000cwv.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.hub.org User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (linux) Cancel-Lock: sha1:hvduhIutAzqnJYM6xKEEfoBgG9k= To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.289 required=5 tests=[AWL=0.289] X-Spam-Score: 0.289 X-Spam-Level: X-Archive-Number: 200602/420 X-Sequence-Number: 17406 "Nik" writes: > I have a table that has only a few records in it at the time, and they > get deleted every few seconds and new records are inserted. Table never > has more than 5-10 records in it. > > However, I noticed a deteriorating performance in deletes and inserts > on it. So I performed vacuum analyze on it three times (twice in a row, > and once two days later). In the statistics it says that the table size > is 863Mb, toast table size is 246Mb, and indexes size is 134Mb, even > though the table has only 5-10 rows in it it. I was wondering how can I > reclaim all this space and improve the performance? You need to run VACUUM ANALYZE on this table very frequently. Based on what you describe, "very frequently" should be on the order of at least once per minute. Schedule a cron job specifically to vacuum this table, with a cron entry like the following: * * * * * /usr/local/bin/vacuumdb -z -t my_table -p 5432 my_database Of course, you need to bring it back down to size, first. You could run CLUSTER on the table to bring it back down to size; that's probably the fastest way... cluster my_table_pk on my_table; VACUUM FULL would also do the job, but probably not as quickly. -- (reverse (concatenate 'string "gro.gultn" "@" "enworbbc")) http://cbbrowne.com/info/sgml.html "Now they can put you in jail if they *THINK* you're gonna commit a crime. Let me say that again, because it sounds vaguely important" --george carlin