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 622CFD77FC for ; Tue, 23 Aug 2005 02:14:25 -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 01445-07 for ; Tue, 23 Aug 2005 05:14:20 +0000 (GMT) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.29]) by svr1.postgresql.org (Postfix) with ESMTP id 714B2D77D9 for ; Tue, 23 Aug 2005 02:14:19 -0300 (ADT) Received: (qmail 18387 invoked from network); 23 Aug 2005 05:14:18 -0000 Received: from dsl081-060-184.sfo1.dsl.speakeasy.net (HELO noodles) ([64.81.60.184]) (envelope-sender ) by mail27.sea5.speakeasy.net (qmail-ldap-1.03) with RC4-MD5 encrypted SMTP for ; 23 Aug 2005 05:14:18 -0000 Subject: Re: unused item pointers? From: "Jeffrey W. Baker" To: Alan Stange Cc: pgsql-performance@postgresql.org In-Reply-To: <430A8F30.7050706@rentec.com> References: <430A8F30.7050706@rentec.com> Content-Type: text/plain Date: Mon, 22 Aug 2005 22:15:08 -0700 Message-Id: <1124774108.6978.7.camel@noodles> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 required=5 tests=[none] X-Spam-Level: X-Archive-Number: 200508/338 X-Sequence-Number: 14085 On Mon, 2005-08-22 at 22:51 -0400, Alan Stange wrote: > Hello all, > > what are unused item pointers and how do I get rid of them? > > We have a fairly large table which is vacuumed daily and reindexed every > weekend. > as you can see we have 235M unused item pointers in the main table and a > few 10's of millions more in other associated tables. > > Please note that the advice "vacuum more often" is a non-starter as the > total time here is already about 3 hours and this is just one table. > This is a fairly active table to which about 20M rows are added and > removed daily. That may be so, but the answer is still to VACUUM more often. Try the autovacuum. If it takes 3 hours with 90% wasted records, it would only take 20 minutes when running properly. You might be able to change your application to avoid generating so many dead rows. For example, test before insert so you don't make a dead tuple on duplicate insert. To repair this table, you can try VACUUM FULL but this is likely to take longer than you find reasonable. I would recommend dump and reload. -jwb