REINDEX

説明

REINDEXは、インデックスのテーブルに保存されたデータを元にインデックスを再構築し、古いインデックスのコピーと置き換えます。 REINDEXの使用には大きく2つの目的があります。

• インデックスが破損してしまい、有効なデータがなくなった場合です。 理論的には決して起こらないことですが、実際には、ソフトウェアのバグやハードウェアの障害により破損することがあります。 REINDEXはこの修復手段を提供します。

• 対象とするインデックスが回収されることがない使用されないインデックスページを多く含む場合です。 これは、特定のアクセスパターン下のPostgreSQLのB-treeインデックスで起こり得ます。 REINDEXは、使用されないページを持たない新しいインデックスを書き直すことでそのインデックスの領域消費量を減少させる手段を提供します。 詳細は項21.2を参照してください。

パラメータ

注釈

ユーザテーブル上の1つのインデックスに破損の疑いがある場合、単にそのインデックスを再構築してください。 テーブル上の全てのインデックスの場合は、REINDEX INDEXかREINDEX TABLEを使用してください。

システムテーブルのインデックスの破損を復旧する必要がある場合はより複雑になります。 この場合、システムに疑わしいインデックス自体を使用しないようにさせることが重要です。 (実際は、このような場合は、破損したインデックスへの依存によりサーバプロセスはその起動時に強制終了してしまうことになるでしょう。) 安全に復旧させるには、システムカタログ検索時のインデックスの使用を抑制する-Pオプションを使用してサーバを起動させなければなりません。

この1つの方法は、postmasterを停止させ、-Pオプションをコマンドラインに入れてスタンドアロン状態のPostgreSQLサーバを起動させることです。 そして、どこまで再構成させたいのかによって、REINDEX DATABASE、REINDEX TABLE、または、REINDEX INDEXコマンドを発行します。 不明な場合は、REINDEX DATABASEを使用して、そのデータベースの全てのシステムインデックスを再構成を選んでください。 そして、スタンドアロン状態のサーバセッションを停止させ、実サーバを再起動してください。 スタンドアロン状態のサーバインタフェースの操作方法についての詳細はpostgresマニュアルページを参照してください。

その他、-Pをコマンドラインオプションに含めて、実サーバセッションを起動させることができます。 これを実現させる方法は、クライアントによって異なります。 しかし、全てのlibpqベースのクライアントでは、クライアントを起動する前にPGOPTIONS環境変数を-Pに設定することで可能です。 この方法では他のクライアントを締め出す必要はありませんが、修復が終わるまで破損したデータベースへの他のユーザの接続を防止する方が良いことに注意してください。

共有システムカタログ(pg_database、pg_group、pg_shadow、pg_tablespace)のいずれかのインデックスが破損した疑いがある場合、修復のためにはスタンドアロンサーバを使用しなければなりません。 マルチユーザモードでは共有カタログの処理を行いません。

共有システムカタログ以外の全てのインデックスでは、REINDEXはクラッシュセーフかつトランザクションセーフです。 共有インデックスに対するREINDEXはクラッシュセーフではありません。 これが、通常の運用状態で実行できない理由です。 スタンドアロンモードで、これらのカタログのインデックス再作成処理中に問題が発生した場合、問題が修正されるまで実サーバを再起動することができなくなります。 (共有インデックスの部分的な再構築に関するよくある兆候は、"index is not a btree"というエラーです。)

REINDEXは、インデックスを削除し再作成するといったインデックスの内容を始めから作り直す操作と似ています。 しかし、ロックに関して異なります。 REINDEXは書き込みをロックしますが、インデックスの元となるテーブルの読み込みはロックしません。 また、処理中の特定のインデックスに対する排他ロックを取得しますので、そのインデックスを使用するための読み込みはブロックされます。 一方、DROP INDEXは瞬間的に元となるテーブルの排他ロックを取得しますので、書き込みも読み込みもブロックされます。 その後に行うCREATE INDEXは書き込みをロックし、読み込みはロックしません。 インデックスは存在しませんので、インデックスを使用するための読み込みはありません。 これは、読み込みはブロックされることはありませんが、そのために強制的に高価なシーケンシャルスキャンが行われることを意味します。 この他、削除し再作成する方法では、キャッシュされた、インデックスを使用する問い合わせ計画を無効にしますが、REINDEXは無効にしないことも重要な違いです。

PostgreSQL 7.4より前まで、REINDEX TABLEはTOASTテーブルに対して自動的に処理を行いませんでした。 そのため、別のコマンドでインデックスを再作成しなければなりませんでした。 これは可能になりましたが、冗長です。

例

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

REINDEX TABLE my_table;

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

REINDEX INDEX my_index;

既に有効かどうかを確認することなく、あるデータベース内の全てのシステムインデックスを再構築します。

$ export PGOPTIONS="-P"
$ psql broken_db
...
broken_db=> REINDEX DATABASE broken_db;
broken_db=> \q

互換性

標準SQLにはREINDEXはありません。