REINDEXコマンドまたは一連の個々の再構築処理を使用して定期的にインデックスを再構築することが価値がある状況があります。

完全に空になったB-treeインデックスページは再利用のために回収されます。 しかしまだ非効率的な領域使用の可能性があります。 ページからわずかを残しほとんどすべてのインデックスキーが削除されたとしても、ページは割り当てられたまま残ります。 各範囲において、わずかを残しほとんどすべてのキーが削除されるようなパターンで使用されると、領域が無駄に使用されることが分かります。 こうした使用状況では、定期的なインデックス再構築を推奨します。

B-tree以外のインデックスが膨張する可能性はまだよく調査されていません。 B-tree以外の任意の種類のインデックスを使用する際には、インデックスの物理容量を定期的に監視することを勧めます。

また、B-treeインデックスでは、新規に構築したインデックスの方が何度も更新されたインデックスよりもアクセスが多少高速です。 新しく構築されたインデックスでは論理的に近接するページが通常物理的にも近接するからです。 （これはB-tree以外のインデックスではあてはまりません。） アクセス速度を向上させるためだけに周期的にインデックスを再構築することは価値があるかもしれません。

REINDEXはすべての状況で安全に簡単に使うことができます。 しかし、このコマンドはテーブルの排他ロックを要求しますので、生成と置き換えの処理を続けて行なうことでインデックスの再構築を実行する方が好ましい場合がしばしばあります。 CONCURRENTLYオプションの付いたCREATE INDEXをサポートする種類のインデックスでは代わりにそのように再構築できます。 それが成功し、結果のインデックスが有効ならば、ALTER INDEXとDROP INDEXを組み合わせて使って、元のインデックスを新しく構築されたものに置き換えることができます。 インデックスが一意性もしくはその他の制約を強制するために使われている場合には、既存の制約を新しいインデックスで強制されるものへ入れ替えるためにALTER TABLEが必要になるかもしれません。 インデックスをこのように再作成するのには制限がありますので、この複数の処理で再構築する代わりの方法を使う前に注意深く検討し、エラーを処理しなければなりません。