説明

<command>REINDEX</command> rebuilds an index using the data stored in the index's table, replacing the old copy of the index. There are several scenarios in which to use <command>REINDEX</command>: REINDEXは、インデックスのテーブルに保存されたデータを使用してインデックスを再構築し、古いインデックスのコピーと置き換えます。 以下にREINDEXが使用される状況を示します。

パラメータ

注釈

If you suspect corruption of an index on a user table, you can simply rebuild that index, or all indexes on the table, using <command>REINDEX INDEX</command> or <command>REINDEX TABLE</command>. ユーザテーブル上の特定のインデックスに破損の疑いがある場合、REINDEX INDEXを使ってそのインデックスを再構築することもできますし、REINDEX TABLEを使ってそのテーブルのすべてのインデックスを再構築することもできます。

Things are more difficult if you need to recover from corruption of an index on a system table. In this case it's important for the system to not have used any of the suspect indexes itself. (Indeed, in this sort of scenario you might find that server processes are crashing immediately at start-up, due to reliance on the corrupted indexes.) To recover safely, the server must be started with the <option>-P</option> option, which prevents it from using indexes for system catalog lookups. システムテーブルのインデックスの破損を復旧する場合の手順はより複雑になります。 この場合、システムによって破損の可能性があるインデックス自体が使用されないようにすることが重要です （実際は、このようなケースでは、破損したインデックスに依存していたため、サーバプロセスが起動時に強制終了してしまう可能性があります）。 安全に復旧させるには、システムカタログ検索時のインデックスの使用を禁止する-Pオプションを使用してサーバを起動しなければなりません。

One way to do this is to shut down the server and start a single-user <productname>PostgreSQL</productname> server with the <option>-P</option> option included on its command line. Then, <command>REINDEX DATABASE</command>, <command>REINDEX SYSTEM</command>, <command>REINDEX TABLE</command>, or <command>REINDEX INDEX</command> can be issued, depending on how much you want to reconstruct. If in doubt, use <command>REINDEX SYSTEM</command> to select reconstruction of all system indexes in the database. Then quit the single-user server session and restart the regular server. See the <xref linkend="app-postgres"/> reference page for more information about how to interact with the single-user server interface. 考えられる方法の1つは次の方法です。まず、サーバを停止して、コマンドラインから-Pオプションを指定してシングルユーザ状態のPostgreSQLサーバを起動します。 そして、再構成する範囲に応じて、REINDEX DATABASE、REINDEX SYSTEM、REINDEX TABLE、または、REINDEX INDEXコマンドを発行します。 範囲が不明な場合は、REINDEX SYSTEMを使用して、そのデータベースの全てのシステムインデックスを再構成してください。 その後、シングルユーザ状態のサーバセッションを停止して、通常のサーバを再起動します。 シングルユーザ状態のサーバインタフェースの操作方法についての詳細は、postgresマニュアルページを参照してください。

Alternatively, a regular server session can be started with <option>-P</option> included in its command line options. The method for doing this varies across clients, but in all <application>libpq</application>-based clients, it is possible to set the <envar>PGOPTIONS</envar> environment variable to <literal>-P</literal> before starting the client. Note that while this method does not require locking out other clients, it might still be wise to prevent other users from connecting to the damaged database until repairs have been completed. その他、コマンドラインで-Pを指定して通常のサーバセッションを起動することもできます。 具体的な方法は、クライアントによって異なります。 しかし、libpqベースのクライアントであれば、クライアントを起動する前に環境変数PGOPTIONSを-Pに設定すれば実現できます。 この方法では他のクライアントを締め出す必要はありませんが、修復が終わるまで破損したデータベースへの他のユーザの接続を防止する方が良いことに注意してください。

<command>REINDEX</command> is similar to a drop and recreate of the index in that the index contents are rebuilt from scratch. However, the locking considerations are rather different. <command>REINDEX</command> locks out writes but not reads of the index's parent table. It also takes an <literal>ACCESS EXCLUSIVE</literal> lock on the specific index being processed, which will block reads that attempt to use that index. In particular, the query planner tries to take an <literal>ACCESS SHARE</literal> lock on every index of the table, regardless of the query, and so <command>REINDEX</command> blocks virtually any queries except for some prepared queries whose plan has been cached and which don't use this very index. In contrast, <command>DROP INDEX</command> momentarily takes an <literal>ACCESS EXCLUSIVE</literal> lock on the parent table, blocking both writes and reads. The subsequent <command>CREATE INDEX</command> locks out writes but not reads; since the index is not there, no read will attempt to use it, meaning that there will be no blocking but reads might be forced into expensive sequential scans. REINDEXは、インデックスの中身を1から作り直すという点では、インデックスを削除してから再作成する処理と似ています。 しかし、ロックに関しては異なります。 REINDEXはインデックスの元となるテーブルの書き込みをロックしますが、読み込みはロックしません。 また、処理中のインデックスに対するACCESS EXCLUSIVEロックを取得するので、そのインデックスを使用する読み込みはブロックされます。 特に、問い合わせプランナは、問い合わせに関わらずテーブルの各インデックスでACCESS SHAREロックを取得しようとしますので、REINDEXは、プランがキャッシュされていて、まさにこのインデックスを使わないプリペアド問い合わせを除く問い合わせをすべて実質的にブロックします。 一方、DROP INDEXは瞬間的に元となるテーブルのACCESS EXCLUSIVEロックを取得するので、書き込みも読み込みもブロックされます。 その後に行うCREATE INDEXでは書き込みのみをロックし、読み込みはロックしません。 インデックスは存在しないので、インデックスを使用する読み込みは発生しません。 したがって、読み込みがブロックされることはありませんが、コストが高いシーケンシャルスキャンの使用を強制されることになるかもしれません。

While <command>REINDEX</command> is running, the <xref linkend="guc-search-path"/> is temporarily changed to <literal>pg_catalog, pg_temp</literal>. 《機械翻訳》REINDEXの実行中、search_pathは一時的にpg_catalog, pg_tempに変更されます。

Reindexing a single index or table requires having the <literal>MAINTAIN</literal> privilege on the table. Note that while <command>REINDEX</command> on a partitioned index or table requires having the <literal>MAINTAIN</literal> privilege on the partitioned table, such commands skip the privilege checks when processing the individual partitions. Reindexing a schema or database requires being the owner of that schema or database or having privileges of the <link linkend="predefined-roles-table"><literal>pg_maintain</literal></link> role. Note specifically that it's thus possible for non-superusers to rebuild indexes of tables owned by other users. However, as a special exception, <command>REINDEX DATABASE</command>, <command>REINDEX SCHEMA</command>, and <command>REINDEX SYSTEM</command> will skip indexes on shared catalogs unless the user has the <literal>MAINTAIN</literal> privilege on the catalog. 《機械翻訳》単一のインデックスまたはテーブルを再インデックスするには、テーブルに対するMAINTAIN権限が必要です。 パーティション化されたインデックスまたはテーブルに対するREINDEXには、パーティション化されたテーブルに対するMAINTAIN権限が必要であることに注意してください。 しかし、このようなコマンドは個々のパーティションを処理する際に権限チェックをスキップします。 スキーマまたはデータベースの再インデックスを実行するには、そのスキーマまたはデータベースの所有者であるか、pg_maintainロールの権限が必要です。 したがって、スーパーユーザ以外のユーザが、他のユーザが所有するテーブルのインデックスを再構築できることに注意してください。 ただし、特別な例外として、ユーザがカタログに対してMAINTAIN権限を持っていない場合、REINDEX DATABASE、REINDEX SCHEMA、およびREINDEX SYSTEMは共有カタログ上のインデックスをスキップします。

Reindexing partitioned indexes or partitioned tables is supported with <command>REINDEX INDEX</command> or <command>REINDEX TABLE</command>, respectively. Each partition of the specified partitioned relation is reindexed in a separate transaction. Those commands cannot be used inside a transaction block when working on a partitioned table or index. パーティションインデックスやパーティションテーブルのインデックス再作成は、それぞれREINDEX INDEX、REINDEX TABLEでサポートされています。 指定されたパーティションリレーションの個々のパーティションが、別々のトランザクションでインデックスを再作成されます。 パーティションテーブルやパーティションインデックスに対して操作する場合、このコマンドをトランザクションブロック内では使えません。

When using the <literal>TABLESPACE</literal> clause with <command>REINDEX</command> on a partitioned index or table, only the tablespace references of the leaf partitions are updated. As partitioned indexes are not updated, it is recommended to separately use <command>ALTER TABLE ONLY</command> on them so as any new partitions attached inherit the new tablespace. On failure, it may not have moved all the indexes to the new tablespace. Re-running the command will rebuild all the leaf partitions and move previously-unprocessed indexes to the new tablespace. パーティションインデックスやパーティションテーブルでTABLESPACE句を使ってREINDEXを行なう場合、リーフパーティションのテーブル空間参照のみが更新されます。 パーティションインデックスは更新されませんので、アタッチされた新しいパーティションが新しいテーブル空間を継承するように、それぞれALTER TABLE ONLYを使うことをお勧めします。 失敗した場合、インデックスはすべて新しいテーブル空間へと移動したわけではないかもしれません。 コマンドを再実行すればリーフパーティションはすべて再構築され、先ほどは処理されなかったインデックスが新しいテーブル空間へと移動します。

If <literal>SCHEMA</literal>, <literal>DATABASE</literal> or <literal>SYSTEM</literal> is used with <literal>TABLESPACE</literal>, system relations are skipped and a single <literal>WARNING</literal> will be generated. Indexes on TOAST tables are rebuilt, but not moved to the new tablespace. SCHEMA、DATABASE、SYSTEMがTABLESPACEと一緒に使われた場合、システムリレーションは飛ばされ、WARNINGが1度出ます。 TOASTテーブルのインデックスは再構築されますが、新しいテーブル空間には移動しません。

postgres=# \d tab
       Table "public.tab"
 Column |  Type   | Modifiers
--------+---------+-----------
 col    | integer |
Indexes:
    "idx" btree (col)
    "idx_ccnew" btree (col) INVALID

例

Rebuild a single index: 単一のインデックスを再構築します。

REINDEX INDEX my_index;

Rebuild all the indexes on the table <literal>my_table</literal>: テーブルmy_table上のすべてのインデックスを再構築します。

REINDEX TABLE my_table;

Rebuild all indexes in a particular database, without trusting the system indexes to be valid already: システムインデックスが有効かどうかを確認することなく、あるデータベース内の全てのインデックスを再構築します。

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

Rebuild indexes for a table, without blocking read and write operations on involved relations while reindexing is in progress: 再インデックスの進行中に、関連するリレーションの読み書きをブロックすることなく、テーブルに対するインデックスを再構築します。

REINDEX TABLE CONCURRENTLY my_broken_table;

互換性

There is no <command>REINDEX</command> command in the SQL standard. 標準SQLにはREINDEXはありません。

関連項目