Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id B76D49F9425 for ; Wed, 18 Oct 2006 19:33:20 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 83755-03 for ; Wed, 18 Oct 2006 19:33:13 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 765279FA1E2 for ; Wed, 18 Oct 2006 19:33:11 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 1AA5E56446; Wed, 18 Oct 2006 17:33:10 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Wed, 18 Oct 2006 17:33:08 -0500 Date: Wed, 18 Oct 2006 17:33:08 -0500 From: "Jim C. Nasby" To: Graham Davis Cc: pgsql-performance@postgresql.org Subject: Re: index growth problem Message-ID: <20061018223307.GC56874@nasby.net> References: <4536A8A3.1050409@refractions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4536A8A3.1050409@refractions.net> X-Operating-System: FreeBSD 6.1-RELEASE-p10 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.13 (2006-08-11) X-Hashcash: 1:20:061018:gdavis@refractions.net::/SDaSOqBk9rhbjLz:000000000000000 00000000000000000000000001l+ X-Hashcash: 1:20:061018:pgsql-performance@postgresql.org::5ODCEVJeCVdAchIz:00000 0000000000000000000000007WUd X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.045 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200610/384 X-Sequence-Number: 21513 On Wed, Oct 18, 2006 at 03:20:19PM -0700, Graham Davis wrote: > I have a question about index growth. > > The way I understand it, dead tuples in indexes were not reclaimed by > VACUUM commands in the past. However, I've read in a few forum posts > that this was changed somewhere between 7.4 and 8.0. There was a change to indexes that made vacuum more effective; I don't remember the details off-hand. > I'm having an issue where my GIST indexes are growing quite large, and > running a VACUUM doesn't appear to remove the dead tuples. For example, > if I check out the size an index before running any VACUUM : > > select pg_relation_size('asset_positions_position_idx'); > pg_relation_size > ------------------ > 11624448 > (1 row) > > The size is about 11Mb. If I run a VACUUM command in verbose, I see > this about the index: > > INFO: index "asset_positions_position_idx" now contains 4373 row > versions in 68 pages > DETAIL: 0 index pages have been deleted, 0 are currently reusable. > CPU 0.00s/0.00u sec elapsed 0.16 sec. > > When I run the same command to find the size after the VACUUM, it hasn't > changed. However, if I drop and then recreate this index, the size > becomes much smaller (almost half the size): > > drop index asset_positions_position_idx; > DROP INDEX > > CREATE INDEX asset_positions_position_idx ON asset_positions USING GIST > (position GIST_GEOMETRY_OPS); > CREATE INDEX > > select pg_relation_size('asset_positions_position_idx'); > pg_relation_size > ------------------ > 6225920 > (1 row) > > Is there something I am missing here, or is the reclaiming of dead > tuples for these indexes just not working when I run a VACUUM? Is it > suppose to work? That's not really a useful test to see if VACUUM is working. VACUUM can only trim space off the end of a relation (index or table), where by 'end' I mean the end of the last file for that relation on the filesystem. This means it's pretty rare for VACUUM to actually shrink files on-disk for tables. This can be even more difficult for indexes (I think it's virtually impossible to shrink a B-tree index file). -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)