Unbalanced Btree Indices ...

From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Unbalanced Btree Indices ...
Date: 2004-03-21 16:06:00
Message-ID: 20040321114449.T98092@ganymede.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


How are we handling that now? I seem to recall someone (Tom?) making some
changes to our btree indices for this ...

For instance, very simplistic example:

m
h t
a l n z

If I remove the 'h' record, does that remain an empty bucket forever, or
does, say, the l get propogated up into its place, or? If I lose 'h' and
'a'?

Basically, at what point, if any, should one do a re-build of their
indexes to clean out the empty buckets? Or does a vacuum automatically do
this for you? or vacuum full?

Assuming that a rebuild is required, is there anyway of seeing how the
index is balanced, to know when to do it?

From what I do find in the docs, though, the REINDEX command states:

"The index in question contains a lot of dead index pages that are not
being reclaimed. This can occur with B-tree indexes in PostgreSQL under
certain access patterns. REINDEX provides a way to reduce the space
consumption of the index by writing a new version of the index without the
dead pages. See Section 21.2 for more information."

while Section 21.2 mentions that it is less required in 7.4 ... but
neither talk about what 'access patterns' would be affected ...

Pointers to docs that I'm not finding most acceptable ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-03-21 16:10:32 Re: Why O_SYNC is faster than fsync on ext3
Previous Message Manfred Spraul 2004-03-21 10:45:18 Re: Why O_SYNC is faster than fsync on ext3