Unbalanced Btree Indices ...

Поиск
Список
Период
Сортировка
От Marc G. Fournier
Тема Unbalanced Btree Indices ...
Дата
Msg-id 20040321114449.T98092@ganymede.hub.org
обсуждение исходный текст
Ответы Re: Unbalanced Btree Indices ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@hub.org           Yahoo!: yscrappy              ICQ: 7615664


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Manfred Spraul
Дата:
Сообщение: Re: Why O_SYNC is faster than fsync on ext3
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Why O_SYNC is faster than fsync on ext3