在某些情况下，值得周期性地使用 REINDEX 命令或一系列单独的重建步骤， 来重建索引。
B-树索引中已经完全变空的索引页会被回收以供重用。不过，仍然可能出现空间利用低效： 如果某个页面上的索引键除了少数几个之外都被删除，该页面仍会保留分配。因此， 在一种使用模式下，如果每个键范围中的大多数但不是全部键最终都被删除， 就会出现糟糕的空间利用。对于这种使用模式，建议定期重建索引。
对于非 B-树索引中的膨胀潜力，人们还没有做过充分研究。 在使用任何非 B-树索引类型时，定期监控索引的物理大小是个好主意。
此外，对 B-树索引而言，新近构建的索引比已经多次更新过的索引在访问时稍快一些， 因为在新建的索引中，逻辑上相邻的页面通常在物理上也彼此相邻。 （这一考虑不适用于非 B-树索引。）即便只是为了提高访问速度， 周期性重建索引也可能是值得的。
REINDEX 在所有情况下都能安全、方便地使用。但由于该命令需要表的排他锁，通常更适合通过一系列创建和替换步骤来重建索引。对于支持使用 CONCURRENTLY 选项执行 CREATE INDEX 的索引类型，可以改用这种方式重新创建。如果创建成功且生成的索引有效，就可以结合 ALTER INDEX 和 DROP INDEX，用新建索引替换原索引。如果索引用于强制唯一性或其他约束，可能需要使用 ALTER TABLE，将现有约束替换为由新索引强制执行的约束。使用这种多步骤重建方法前，应仔细评估，因为能够用这种方式重建的索引存在限制，而且必须处理错误。