他のバージョンの文書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

名前

REINDEX -- インデックスの再構築

概要

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

説明

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

パラメータ

DATABASE

指定したデータベースの全てのシステムインデックスを再作成します。 ユーザテーブル上のインデックスは処理されません。 また、スタンドアロンモード(後述)以外では、共有システムカタログは飛ばされます。

TABLE

指定したテーブルの全インデックスを再作成します。 テーブルに2次的な"TOAST"テーブルがあっても、同様にインデックスを再作成します。

INDEX

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

name

インデックスを再作成するデータベース、テーブル、インデックスを指定する名前です。 テーブルとインデックスはスキーマで修飾可能です。 今のところ、REINDEX DATABASEは現在のデータベースのインデックスのみを再作成することができます。 そのため、パラメータは現在のデータベース名と一致する必要があります。

FORCE

このオプションは廃止されました。 指定されても無視されます。

注釈

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

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

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

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

共有システムカタログ(pg_databasepg_grouppg_shadowpg_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はありません。