PostgreSqlインデックスを再構築する操作

PostgreSqlデータベースの再構成インデックスはREINDEX命令により実現されます。name
その文法は:

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

以下の説明で説明する必要があります。
1、ソフトウェアの不具合またはハードウェアの原因によりインデックスが利用できなくなり、インデックスのデータが利用できなくなりました。
2、インデックスに空のページが多く含まれている場合、または空のページに近い場合、これはb-tree索引で発生します。Reindexは空間を空けてどのような無駄なページを解放しますか？
3、PostgreSqlデータベースシステムは記憶パラメータを修正しました。再構築が必要でないと無効になります。
4、併合索引の作成に失敗し、失効した索引を残しました。このようなインデックスは使用されませんが、再構成されてから使えます。インデックスの再構成は同時に実行できません。
インデックスコマンドを再構成するパラメータを紹介します。
1、INDEX再構築指定インデックス。
2、TABLE再構築指定表のすべての索引は下級TOAST表を含む。
3、DATABASE再構築指定データベースのすべてのインデックスは、システム共有インデックスも実行されます。このレベルの再構成は、もう一つのトランザクションブロックでは実行できないことに留意されたい。
4、SYSTEM再構築このシステムのインデックスは現在のデータベースを含みます。共有システムにはインデックスページが含まれていますが、ユーザ自身のテーブルは処理されておらず、同じブロックでも実行できません。
5、Nameは異なるレベルの索引の名称に従います。
6、FOCEはもう廃止されました。書いても無視されました。
例:

REINDEX INDEX my_index;
REINDEX TABLE my_table;
REINDEX DATABASE broken_db;

また注意すべき点は：
1、インデックスの異なるレベルの再構築には、テーブルのような異なる権限が必要です。このテーブルの権限が必要です。つまり、スーパーユーザーのpostgresがこの権限を持つように、インデックスを操作する権限が必要です。
インデックスを再構築する目的はインデックスのデータが信頼できない場合、すなわちコストの計算に対して偏差が大きいため、最適な実行計画を得て性能の最適化に失敗するためです。
3、インデックスの再構成は、最初にすべてを削除してからインデックスを作成するのと似ていますが、インデックスの項目は再開始されます。再構成時に現在のインデックスは書き込みできません。この時は排他的なロックがあります。
4、8、1のバージョンの前にREINDEX DATABASEはシステムインデックスのみを含み、希望のすべての指定データベースの索引ではない。7.4バージョンの前にREINDEX TABLEは自動的に下位TOASTテーブルを実行しません。
TOASTテーブルの意味について：
TOAST直訳ではスライスパンという意味です。全称はThe Oversized-Attribute Storrage Techniqueです。
どうしてOVERSIZED-ARTTRIBTEがありますか？なぜかというと、PostgreSQLでは、一つのレコードはPAGEにまたがって保存できないので、
PAGEを越えるにはTOAST（つまりunaligned）を使用して保存しなければなりません。
TOASTテーブルは独立して作成できません。普通のテーブルにmain、extededまたはexternalの格納フォーマットが含まれているフィールドだけがあります。システムは自動的に一般のテーブルと関連するTOASTテーブルを作成します。
一つのレコードが保存されている場合（圧縮すれば圧縮されたサイズを計算する）はTOAST_より大きい。TUPLE_THRESHOLD（通常は2 kB）という値はTOASTテーブルに格納されます。
このとき、一般テーブルのこのフィールドには、TOASTを指すテーブルブルやchunk_が含まれています。IDのデータは、このフィールドのレコードを見つけることができます。
補足：pgインデックスが遭遇した穴を削除します。
正常にインデックスを削除する時、下記のエラーを報告します。

そしてインデックスパスを設定するだけでOKです。
set search ch upath=bi_dpa;
以上は個人の経験ですので、参考にしていただければと思います。間違いがあったり、完全に考えていないところがあれば、教えてください。