他のバージョンの文書 15 | 14 | 13 | 12 | 11 | 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

REINDEX

Name

REINDEX  -- 破損したインデックスの再構築

Synopsis

REINDEX { TABLE | DATABASE | INDEX } name [ FORCE ]
  

入力

TABLE

指定したテーブルの全インデックスを再作成します。

DATABASE

指定したデータベースの全てのシステムインデックスを再作成します。(ユーザテーブルのインデックスは含まれません。)

INDEX

指定したインデックスを再作成します。

name

インデックスの再作成を行なうテーブル/データベース/インデックスの名前を指定します。 テーブルおよびインデックス名はスキーマで修飾することができます。

FORCE

強制的にシステムインデックスの再構築を行ないます。このキーワードがなければ、REINDEX は無効とされていないシステムインデックスを処理しません。FORCE を REINDEX INDEX や ユーザインデックスに対する再作成に付与することは意味がありません。

出力

REINDEX

テーブルのインデックス再作成が正常に終了した場合に返されるメッセージです。

説明

REINDEX は、破損したシステムインデックスの修復に使われます。理論的にはこれは必要なものではありませんが、実際のところインデックスはソフトウェアのバグやハードウェア障害により破損することがあります。REINDEX はこの修復手段を提供します。

また REINDEX は、他の方法では回収できない使用不可能なインデックスを取り除きます。 詳細については、このマニュアルの「定常的なインデックスの再作成」 に関する節を参照してください。

ユーザテーブルのインデックスが破損したかもしれない場合、REINDEX INDEX もしくはREINDEX TABLE を使用して、そのインデックスやそのテーブル上の全てのインデックスを簡単に再作成することができます。

Note: ユーザテーブルの破損したインデックスを扱うもう一つの方法は、ただそのインデックスを破棄し、再作成することです。他のテーブルに対する操作と同じような操作で管理できますので、実際はこの方法の方が好まれるかもしれません。REINDEX はテーブルの排他的ロックを獲得しますが、CREATE INDEX はテーブルへの書き込みのみをロックし、読み込みはロックしません。

システムテーブルのインデックスの破損を復旧する必要がある場合はより複雑になります。この場合、疑わしいインデックス自体を使用しないようにバックエンドに復旧処理を実行させることが重要です。 (実際は、このような場合は、破損したインデックスへの依存によりバックエンドはその起動時に強制終了してしまうことになるでしょう。)安全に復旧させるには、postmaster を停止させ、-Oおよび-Pコマンドラインオプション(これらはそれぞれシステムテーブルの変更を許可し、システムインデックスの使用を抑制するオプションです。)を使用してスタンドアロン状態のPostgreSQL バックエンドを起動させなければなりません。そして、どこまで再構成させたいのかによって、REINDEX INDEXREINDEX TABLE、または、REINDEX DATABASE コマンドを発行します。不明な場合は、REINDEX DATABASE FORCE を使用して、強制的にそのデータベースの全てのシステムインデックスを再構成して下さい。そして、スタンドアロン状態のバックエンドを停止させ、postmaster を再起動して下さい。

ほとんどのユーザにとって、スタンドアロン状態のバックエンドを使用する機会は上の場合のみですので、使用上の注意事項を以下に示します。

より詳細については postgres のリファレンスページを参照して下さい。

使用方法

mytable テーブルのインデックスを再作成します。

REINDEX TABLE mytable;
   

1つのインデックスを再構築します。

REINDEX INDEX my_index;
   

全てのシステムインデックスを再構築します。 (これは、スタンドアロン状態のバックエンドでのみ動作します。)

REINDEX DATABASE my_database FORCE;
   

互換性

SQL92

SQL92にはREINDEXはありません。