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. The potential for bloat is not indefinite — at worst
there will be one key per page — but it may still be worthwhile
to schedule periodic reindexing for indexes that have such usage
patterns.

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.