バージョンごとのドキュメント一覧

REINDEX

REINDEX <refpurpose>rebuild indexes</refpurpose> — インデックスを再構築する

概要

REINDEX [ ( option [, ...] ) ] { INDEX | TABLE | SCHEMA } [ CONCURRENTLY ] name
REINDEX [ ( option [, ...] ) ] { DATABASE | SYSTEM } [ CONCURRENTLY ] [ name ]


<phrase>where <replaceable class="parameter">option</replaceable> can be one of:</phrase>

ここでoptionは以下の一つです。

    CONCURRENTLY [ boolean ]
    TABLESPACE new_tablespace
    VERBOSE [ boolean ]

説明

<title>Description</title>

<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が使用される状況を示します。

  • An index has become corrupted, and no longer contains valid data. Although in theory this should never happen, in practice indexes can become corrupted due to software bugs or hardware failures. <command>REINDEX</command> provides a recovery method. インデックスが破損してしまい、有効なデータがなくなった場合です。 理論的には決して起こらないはずですが、実際には、ソフトウェアのバグやハードウェアの障害によりインデックスが破損することがあります。 REINDEXはこの修復手段を提供します。

  • An index has become <quote>bloated</quote>, that is it contains many empty or nearly-empty pages. This can occur with B-tree indexes in <productname>PostgreSQL</productname> under certain uncommon access patterns. <command>REINDEX</command> provides a way to reduce the space consumption of the index by writing a new version of the index without the dead pages. See <xref linkend="routine-reindex"/> for more information. インデックスが膨張状態、つまり、多くの空、もしくは、ほとんど空のページを持つ状態になっている場合です。 この状況は、PostgreSQLのB-treeインデックスが特定の普通でないパターンでアクセスされた場合に起こり得ます。 REINDEXを使って、使用されないページを取り除いた新しいインデックス作成すると、インデックスの領域消費量を減少することができます。 詳細は25.2を参照してください。

  • You have altered a storage parameter (such as fillfactor) for an index, and wish to ensure that the change has taken full effect. インデックスの格納パラメータ(フィルファクタなど)を変更し、この変更を確実に有効にしたい場合です。

  • If an index build fails with the <literal>CONCURRENTLY</literal> option, this index is left as <quote>invalid</quote>. Such indexes are useless but it can be convenient to use <command>REINDEX</command> to rebuild them. Note that only <command>REINDEX INDEX</command> is able to perform a concurrent build on an invalid index. CONCURRENTLYオプションをつけたインデックス作成が失敗すると、このインデックスは無効として残されます。 こうしたインデックスは使用されませんが、REINDEXを使用して再作成するのが便利かもしれません。 REINDEX INDEXだけが無効なインデックスでの同時構築を実行できることに注意してください。

パラメータ

<title>Parameters</title>
INDEX

Recreate the specified index. This form of <command>REINDEX</command> cannot be executed inside a transaction block when used with a partitioned index. 指定したインデックスを再作成します。 この構文のREINDEXは、パーティションインデックスと使われる場合にはトランザクションブロック内で実行できません。

TABLE

Recreate all indexes of the specified table. If the table has a secondary <quote>TOAST</quote> table, that is reindexed as well. This form of <command>REINDEX</command> cannot be executed inside a transaction block when used with a partitioned table. 指定したテーブルの全インデックスを再作成します。 テーブルに2次的なTOASTテーブルがある場合、それについてもインデックスを再作成します。 この構文のREINDEXは、パーティションテーブルと使われる場合にはトランザクションブロック内で実行できません。

SCHEMA

Recreate all indexes of the specified schema. If a table of this schema has a secondary <quote>TOAST</quote> table, that is reindexed as well. Indexes on shared system catalogs are also processed. This form of <command>REINDEX</command> cannot be executed inside a transaction block. 指定したスキーマのすべてのインデックスを再作成します。 このスキーマのテーブルが二次的なTOASTテーブルを持っている場合は、そのインデックスも再作成されます。 共有システムカタログのインデックスも処理されます。 この構文のREINDEXはトランザクションブロック内で実行できません。

DATABASE

Recreate all indexes within the current database, except system catalogs. Indexes on system catalogs are not processed. This form of <command>REINDEX</command> cannot be executed inside a transaction block. システムカタログを除く、現在のデータベースのすべてのインデックスを再作成します。 システムカタログのインデックスは処理されません この構文のREINDEXをトランザクションブロック内で実行できません。

SYSTEM

Recreate all indexes on system catalogs within the current database. Indexes on shared system catalogs are included. Indexes on user tables are not processed. This form of <command>REINDEX</command> cannot be executed inside a transaction block. 現在のデータベースのシステムカタログに対するすべてのインデックスを再作成します。 共有システムカタログのインデックスも含みます。 ユーザテーブルのインデックスは処理されません。 この構文のREINDEXをトランザクションブロック内で実行できません。

name

The name of the specific index, table, or database to be reindexed. Index and table names can be schema-qualified. Presently, <command>REINDEX DATABASE</command> and <command>REINDEX SYSTEM</command> can only reindex the current database. Their parameter is optional, and it must match the current database's name. インデックスを再作成するインデックス、テーブル、データベースの名前です。 インデックスとテーブルの名前はスキーマ修飾可能です。 現状では、REINDEX DATABASEREINDEX SYSTEMは現在のデータベースのインデックスのみを再作成することができます。 このパラメータは省略可能で、現在のデータベース名と一致する必要があります。

CONCURRENTLY

When this option is used, <productname>PostgreSQL</productname> will rebuild the index without taking any locks that prevent concurrent inserts, updates, or deletes on the table; whereas a standard index rebuild locks out writes (but not reads) on the table until it's done. There are several caveats to be aware of when using this option &mdash; see <xref linkend="sql-reindex-concurrently"/> below. このオプションが使われると、PostgreSQLは、そのテーブルで同時実行される挿入、更新、削除を妨げるようなロックを取得せずにインデックスを再構築します。一方、標準のインデックス再構築は終了するまでテーブルの書き込みをロックします(読み込みはロックしません)。 このオプションを使用する場合に注意すべき点がいくつかあります—下記のインデックスを同時に再構築を参照してください。

For temporary tables, <command>REINDEX</command> is always non-concurrent, as no other session can access them, and non-concurrent reindex is cheaper. 一時テーブルに対してはREINDEXは常に同時再作成ではありません。他のセッションはアクセスできませんし、同時でないインデックス再作成の方がより安価だからです。

TABLESPACE

Specifies that indexes will be rebuilt on a new tablespace. 新しいテーブル空間でインデックスを再構築することを指定します。

VERBOSE

Prints a progress report as each index is reindexed. 各インデックスが再作成されるときに、進捗レポートを表示します。

boolean

Specifies whether the selected option should be turned on or off. You can write <literal>TRUE</literal>, <literal>ON</literal>, or <literal>1</literal> to enable the option, and <literal>FALSE</literal>, <literal>OFF</literal>, or <literal>0</literal> to disable it. The <replaceable class="parameter">boolean</replaceable> value can also be omitted, in which case <literal>TRUE</literal> is assumed. 選択したオプションをオンにするかオフにするか指定します。 オプションを有効にするにはTRUEONまたは1と、無効にするにはFALSEOFFまたは0と書くことができます。 boolean値は省略することもでき、その場合にはTRUEと仮定されます。

new_tablespace

The tablespace where indexes will be rebuilt. インデックスが再構築されるテーブル空間です。

注釈

<title>Notes</title>

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 DATABASEREINDEX SYSTEMREINDEX 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では書き込みのみをロックし、読み込みはロックしません。 インデックスは存在しないので、インデックスを使用する読み込みは発生しません。 したがって、読み込みがブロックされることはありませんが、コストが高いシーケンシャルスキャンの使用を強制されることになるかもしれません。

Reindexing a single index or table requires being the owner of that index or table. Reindexing a schema or database requires being the owner of that schema or database. Note specifically that it's thus possible for non-superusers to rebuild indexes of tables owned by other users. However, as a special exception, when <command>REINDEX DATABASE</command>, <command>REINDEX SCHEMA</command> or <command>REINDEX SYSTEM</command> is issued by a non-superuser, indexes on shared catalogs will be skipped unless the user owns the catalog (which typically won't be the case). Of course, superusers can always reindex anything. 単一インデックスまたは単一テーブルのインデックス再作成を行うには、そのインデックスまたはテーブルの所有者でなければなりません。 スキーマまたはデータベースに対するインデックス再作成を行うには、そのスキーマまたはデータベースの所有者でなければなりません。 したがって、非スーパーユーザが他のユーザが所有するテーブルのインデックスを再作成できることに特に注意してください。 しかし、特別な例外として、REINDEX DATABASEREINDEX SCHEMAREINDEX 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 INDEXREINDEX 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. SCHEMADATABASESYSTEMTABLESPACEと一緒に使われた場合、システムリレーションは飛ばされ、WARNINGが1度出ます。 TOASTテーブルのインデックスは再構築されますが、新しいテーブル空間には移動しません。

<refsect2 id="sql-reindex-concurrently" xreflabel="Rebuilding Indexes Concurrently">

インデックスを同時に再構築

<title>Rebuilding Indexes Concurrently</title>

Rebuilding an index can interfere with regular operation of a database. Normally <productname>PostgreSQL</productname> locks the table whose index is rebuilt against writes and performs the entire index build with a single scan of the table. Other transactions can still read the table, but if they try to insert, update, or delete rows in the table they will block until the index rebuild is finished. This could have a severe effect if the system is a live production database. Very large tables can take many hours to be indexed, and even for smaller tables, an index rebuild can lock out writers for periods that are unacceptably long for a production system. インデックスの再構築は、通常のデータベース操作を妨げることがあります。 通常、PostgreSQLはインデックスが再構築されるテーブルへの書き込みをロックし、一度のテーブル走査で全インデックスの構築を実行します。 他のトランザクションはテーブルを読み込めますが、そのテーブルで行を挿入、更新、削除しようとするとインデックスの再構築が終わるまでブロックされます。 実行中の運用状態のデータベースシステムの場合、これは重大な影響を与えるかもしれません。 非常に大規模なテーブルに対するインデックス作成は何時間もかかることがあり得ます。また小規模なテーブルであっても、インデックス再構築により、運用状態のシステムとしては受け入れられないほど長い時間、書き込みロックがかかる可能性があります。

<productname>PostgreSQL</productname> supports rebuilding indexes with minimum locking of writes. This method is invoked by specifying the <literal>CONCURRENTLY</literal> option of <command>REINDEX</command>. When this option is used, <productname>PostgreSQL</productname> must perform two scans of the table for each index that needs to be rebuilt and wait for termination of all existing transactions that could potentially use the index. This method requires more total work than a standard index rebuild and takes significantly longer to complete as it needs to wait for unfinished transactions that might modify the index. However, since it allows normal operations to continue while the index is being rebuilt, this method is useful for rebuilding indexes in a production environment. Of course, the extra CPU, memory and I/O load imposed by the index rebuild may slow down other operations. PostgreSQLは最小限の書き込みロックでのインデックス再構築をサポートしています。 REINDEXCONCURRENTLYオプションをつけることでこの方式が行われます。 このオプションを使うと、PostgreSQLは再構築が必要な各インデックスに関してテーブルを2回走査しなければなりません。さらに、潜在的にそのインデックスを使用する可能性がある、実行中のすべてのトランザクションが終わるまで待機しなければなりません。 したがって、この方式は通常のインデックス再構築よりも総作業時間がかかり、また、インデックスを修正する可能性のある終了していないトランザクションが待つ必要がありますので、完了するまでの時間が非常に長くなります。 しかし、インデックス再構築中に通常の操作を続けることができますので、この方式は運用環境でのインデックス再構築に有用です。 もちろん、インデックス再構築によりCPUやメモリ、入出力に余分に負荷がかかりますので、他の操作が低速になる可能性があります。

The following steps occur in a concurrent reindex. Each step is run in a separate transaction. If there are multiple indexes to be rebuilt, then each step loops through all the indexes before moving to the next step. 同時実行再インデックスは以下のような段階で行なわれます。 各段階は分離したトランザクション内で実行されます。 複数のインデックスを再構築する場合、次の段階に移る前にすべてのインデックスに対して各段階が繰り返されます。

  1. A new transient index definition is added to the catalog <literal>pg_index</literal>. This definition will be used to replace the old index. A <literal>SHARE UPDATE EXCLUSIVE</literal> lock at session level is taken on the indexes being reindexed as well as their associated tables to prevent any schema modification while processing. カタログpg_indexに新しく一時的なインデックス定義が追加されます。 この定義は古いインデックスを置き換えるのに使われます。 処理中は、再インデックスされるインデックスと関連するテーブルに対して、セッションレベルでのSHARE UPDATE EXCLUSIVEロックを取得します。スキーマが修正されないようにするためです。

  2. A first pass to build the index is done for each new index. Once the index is built, its flag <literal>pg_index.indisready</literal> is switched to <quote>true</quote> to make it ready for inserts, making it visible to other sessions once the transaction that performed the build is finished. This step is done in a separate transaction for each index. インデックス構築の第1段階は新しいインデックスそれぞれに対して行なわれます。 インデックスが一度構築されれば、挿入の準備ができたということで、そのフラグpg_index.indisreadytrueに切り替わります。構築を実行したトランザクションが終わった後で、他のセッションから見えるようになります。 この過程は各インデックスに対して分離したトランザクションで行なわれます。

  3. Then a second pass is performed to add tuples that were added while the first pass was running. This step is also done in a separate transaction for each index. 次に、第1段階実行中に追加されたタプルを追加する第2段階が行なわれます。 この過程は各インデックスに対して分離したトランザクションで行なわれます。

  4. All the constraints that refer to the index are changed to refer to the new index definition, and the names of the indexes are changed. At this point, <literal>pg_index.indisvalid</literal> is switched to <quote>true</quote> for the new index and to <quote>false</quote> for the old, and a cache invalidation is done causing all sessions that referenced the old index to be invalidated. インデックスを参照する制約は、すべて新しいインデックス定義を参照するよう変更され、インデックスの名前が変更されます。 この時点で、pg_index.indisvalidは新しいインデックスに対してはtrueに切り替えられ、古いものに対してはfalseに切り替えられます。そして、古いインデックスを参照するセッションをすべて無効にするためキャッシュの無効化が行なわれます。

  5. The old indexes have <literal>pg_index.indisready</literal> switched to <quote>false</quote> to prevent any new tuple insertions, after waiting for running queries that might reference the old index to complete. 古いインデックスを参照している可能性のある実行中の問い合わせが完了するのをまってから、新しいタプルが挿入されないように古いインデックスはpg_index.indisreadyfalseに切り替えられます。

  6. The old indexes are dropped. The <literal>SHARE UPDATE EXCLUSIVE</literal> session locks for the indexes and the table are released. 古いインデックスが削除されます。 インデックスやテーブルに対するSHARE UPDATE EXCLUSIVEセッションロックは解放されます。

If a problem arises while rebuilding the indexes, such as a uniqueness violation in a unique index, the <command>REINDEX</command> command will fail but leave behind an <quote>invalid</quote> new index in addition to the pre-existing one. This index will be ignored for querying purposes because it might be incomplete; however it will still consume update overhead. The <application>psql</application> <command>\d</command> command will report such an index as <literal>INVALID</literal>: インデックスの再構築中に、一意性インデックスでの一意性違反などの問題が発生したら、REINDEXコマンドは失敗しますが、既に存在しているものに加えて無効な新しいインデックスを残します。 このインデックスは不完全な可能性がありますので、問い合わせの目的では無視されます。しかし、更新のオーバーヘッドは消費し続けるでしょう。 psql \dコマンドはそのようなインデックスをINVALIDと報告します。

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

If the index marked <literal>INVALID</literal> is suffixed <literal>ccnew</literal>, then it corresponds to the transient index created during the concurrent operation, and the recommended recovery method is to drop it using <literal>DROP INDEX</literal>, then attempt <command>REINDEX CONCURRENTLY</command> again. If the invalid index is instead suffixed <literal>ccold</literal>, it corresponds to the original index which could not be dropped; the recommended recovery method is to just drop said index, since the rebuild proper has been successful. INVALIDと印づけられたインデックスに接尾辞ccnewがついている場合、それは同時実行操作中に作られた一時的なインデックスに対応します。お勧めの回復法はDROP INDEXを使ってそれを削除して、再度REINDEX CONCURRENTLYを試みることです。 無効なインデックスにその代わりに接尾辞ccoldがついている場合、それは削除できなかった元のインデックスに対応します。 正式な再構築は成功していますので、お勧めの回復法は単に前記のインデックスを削除することです。

Regular index builds permit other regular index builds on the same table to occur simultaneously, but only one concurrent index build can occur on a table at a time. In both cases, no other types of schema modification on the table are allowed meanwhile. Another difference is that a regular <command>REINDEX TABLE</command> or <command>REINDEX INDEX</command> command can be performed within a transaction block, but <command>REINDEX CONCURRENTLY</command> cannot. 通常のインデックス構築は、同じテーブルでの他の通常のインデックス構築を許しますが、同時実行インデックス構築は1つだけが一度に1つのテーブルでできます。 どちらの場合でも、その間のそのテーブルでの他の種類のスキーマ修正は認められていません。 もう一つの違いは、通常のREINDEX TABLEREINDEX INDEXコマンドはトランザクションブロックの内側で実行できますが、REINDEX CONCURRENTLYはできないことです。

Like any long-running transaction, <command>REINDEX</command> on a table can affect which tuples can be removed by concurrent <command>VACUUM</command> on any other table. 他の時間のかかるトランザクションと同じく、あるテーブルに対するREINDEXは、その他のテーブルに対する同時実行中のVACUUMによりどのタプルが削除できるかに影響します。

<command>REINDEX SYSTEM</command> does not support <command>CONCURRENTLY</command> since system catalogs cannot be reindexed concurrently. システムカタログは同時実行で再インデックスできませんので、REINDEX SYSTEMCONCURRENTLYをサポートしません。

Furthermore, indexes for exclusion constraints cannot be reindexed concurrently. If such an index is named directly in this command, an error is raised. If a table or database with exclusion constraint indexes is reindexed concurrently, those indexes will be skipped. (It is possible to reindex such indexes without the <command>CONCURRENTLY</command> option.) さらに、排他制約に対するインデックスは同時実行で再インデックスできません。 このコマンドでそのようなインデックスの名前が直接指定されたら、エラーが起きます。 排他制約インデックスのあるテーブルやテータベースが同時実行で再インデックスされる場合、そのインデックスは飛ばされます。 (そのようなインデックスをCONCURRENTLYオプションなしで再インデックスすることは可能です。)

Each backend running <command>REINDEX</command> will report its progress in the <structname>pg_stat_progress_create_index</structname> view. See <xref linkend="create-index-progress-reporting"/> for details. REINDEXを実行している各バックエンドはその進捗をpg_stat_progress_create_indexビューで報告します。 詳細は28.4.4を参照してください。

<title>Examples</title>

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;

互換性

<title>Compatibility</title>

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

関連項目

<title>See Also</title> CREATE INDEX, DROP INDEX, reindexdb, 28.4.4