他のバージョンの文書10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

22.2. 定常的なインデックスの再作成

定期的にREINDEXコマンドを使用してインデックスを再構築することが価値がある状況があります

7.4より前のリリースのPostgreSQLでは、B-treeインデックス内に内部領域の回収機能がなかったことによる"インデックスの膨張"を防ぐために、周期的なインデックス再構築がしばしば必要とされました。 時間経過と共にインデックスキーの範囲が変わるような状況、例えば、テーブル中のタイムスタンプに対するインデックスがあり、かつ、古い項目が削除されるような状況では、不要となったキー範囲の一部に対するインデックスページが再利用のために回収されませんので、そのインデックスは膨張します。 時間がたつと、インデックスは、そのインデックスに含まれる有用なデータ量よりも非常に大きなサイズになります。

PostgreSQL 7.4以降では、完全に空になったインデックスページは再利用のために回収されます。 まだ非効率的な領域使用の可能性があります。 ページからわずかを残しほとんどすべてのインデックスキーが削除されたとしても、ページは割り当てられたまま残ります。 各範囲において、わずかを残しほとんどすべてのキーが削除されるようなパターンで使用されると、領域が無駄に使用されることが分かります。 この膨張の可能性には限界があります。 悪くても、各ページには1つのキーがあります。 しかし、こうしたパターンを持つインデックスに対して周期的なインデックス再構築を行う価値はまだあるかもしれません。

B-tree以外のインデックスが膨張する可能性はまだよく分かっていません。 B-tree以外のインデックス種類を使用する時には、インデックスの物理サイズに注意を払うことを勧めます。

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