In some situations it is worthwhile to rebuild indexes periodically
with the REINDEX
command.
In PostgreSQL releases before 7.4, periodic reindexing
was frequently necessary to avoid "index bloat", due to lack of
internal space reclamation in B-tree indexes. Any situation in which the
range of index keys changed over time — for example, an index on
timestamps in a table where old entries are eventually deleted —
would result in bloat, because index pages for no-longer-needed portions
of the key range were not reclaimed for re-use. Over time, the index size
could become indefinitely much larger than the amount of useful data in it.
In PostgreSQL 7.4 and later, index pages that have become
completely empty are reclaimed for re-use. There is still a possibility
for inefficient use of space: if all but a few index keys on a page have
been deleted, the page remains allocated. So a usage pattern in which all
but a few keys in each range are eventually deleted will see poor use of
space. For such usage patterns, periodic reindexing is recommended.
The potential for bloat in non-B-tree indexes has not been well
characterized. It is a good idea to keep an eye on the index's physical
size when using any non-B-tree index type.
Also, for B-tree indexes a freshly-constructed index is somewhat faster to
access than one that has been updated many times, because logically
adjacent pages are usually also physically adjacent in a newly built index.
(This consideration does not currently apply to non-B-tree indexes.) It
might be worthwhile to reindex periodically just to improve access speed.