有时候我们值得用 REINDEX 命令周期的重建索引。
在 PostgreSQL 版本 7.4 之前，我们经常有必要避免"索引膨胀"， 因为缺乏在 B-tree 索引内部的空间恢复机制。一个情况是就是索引健字的范围随着时间而变化 — 比如，一个在某个表的时间戳上的索引，随着时间的推移，旧的记录会最终被删除 — 就会导致膨胀，因为那些用于不再使用的键字范围的索引页面不回得到重复使用。 随着时间的推移，索引的尺寸可能会变得比里面的有用的数据大得多。
从 PostgreSQL 7.4 开始，那些已经完全清空的索引页会得到重复使用。 不过这样仍然会有不充分使用空间的可能：如果一个页面中大多数索引键字被删除，只留下很少的部分呢， 那么该页仍然将被分配。所以，如果使用模式是这样的：每个范围里除了少数键字之外，其他大部分键字最终都被删除； 那么这样也会导致空间的低效使用。膨胀的可能性不是无穷的 — 最差的情况是每个页面至少还有一个键字 — 但是对这样的使用模式，我们可能仍然值得安排周期性的重新索引。
对于非 B-tree 索引的膨胀可能还没有很好地定量分析。 在使用非 B-tree 索引的时候保持对索引的物理尺寸的监控是个很好的主意。
还有，对于 B-tree 索引，一个新建立的索引从某种意义上比更新了多次的访问起来要快， 因为在新建立的索引上，逻辑上连接的页面通常物理上也连接在一起。 （这样的考虑目前并不适用于非 B-tree 索引。）仅仅从提高访问速度角度出发， 可能我们也值得周期性的重建索引。