X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 3D572538EF for ; Thu, 21 Apr 2005 16:33:09 -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 77158-08 for ; Thu, 21 Apr 2005 19:33:07 +0000 (GMT) Received: from squigy.ddm.wox.org (p223ka.xDSL-1mm.sentex.ca [64.7.151.224]) by svr1.postgresql.org (Postfix) with ESMTP id F06AA5381C for ; Thu, 21 Apr 2005 16:33:04 -0300 (ADT) Received: from rama.ddm.wox.org (rama.ddm.wox.org [172.20.152.20]) by squigy.ddm.wox.org (Postfix) with ESMTP id B6B688B802 for ; Thu, 21 Apr 2005 15:33:05 -0400 (EDT) Received: by rama.ddm.wox.org (Postfix, from userid 5000) id 9862F73043; Thu, 21 Apr 2005 15:33:05 -0400 (EDT) Date: Thu, 21 Apr 2005 15:33:05 -0400 From: Dave Chapeskie To: pgsql-perform Subject: Re: Index bloat problem? Message-ID: <20050421193305.GA84813@ddm.wox.org> Mail-Followup-To: Dave Chapeskie , pgsql-perform References: <20050421173855.76286.qmail@web51410.mail.yahoo.com> <200504211044.48794.josh@agliodbs.com> <4267EFF9.2000908@rentec.com> <200504211128.43937.josh@agliodbs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504211128.43937.josh@agliodbs.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.1 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200504/592 X-Sequence-Number: 11989 On Thu, Apr 21, 2005 at 11:28:43AM -0700, Josh Berkus wrote: > Michael, > > > ....Every five minutes, DBCC INDEXDEFRAG will report to the user an > > estimated percentage completed. DBCC INDEXDEFRAG can be terminated at > > any point in the process, and *any completed work is retained.*" > > Keen. Sounds like something for our TODO list. > > -- > Josh Berkus > Aglio Database Solutions > San Francisco See http://archives.postgresql.org/pgsql-general/2005-03/msg01465.php for my thoughts on a non-blocking alternative to REINDEX. I got no replies to that message. :-( I've almost got a working solution integrated in the backend that does correct WAL logging and everything. (Writing the code to write and replay WAL logs for complicated operations can be very annoying!) For now I've gone with a syntax of: REINDEX INDEX btree_index_name INCREMENTAL; (For now it's not a proper index AM (accessor method), instead the generic index code knows this is only supported for btrees and directly calls the btree_compress function.) It's not actually a REINDEX per-se in that it doesn't rebuild the whole index. It holds brief exclusive locks on the index while it shuffles items around to pack the leaf pages fuller. There were issues with the code I attached to the above message that have been resolved with the new code. With respect to the numbers provided in that e-mail the new code also recycles more pages than before. Once I've finished it up I'll prepare and post a patch. -- Dave Chapeskie OpenPGP Key ID: 0x3D2B6B34