CLUSTERを使用して、インデックスでテーブルを並べ替えることを検討しています。このテーブルデータの再作成により、既存のすべてのインデックスが肥大化するか、役に立たなくなることがわかります。CLUSTERの後にREINDEXが必要であるという兆候を見てきました。CLUSTER が REINDEXを行うことを示す他の参照を見つけました。公式ドキュメントは、（それがCLUSTER後にANALYZEを実行している示唆んが）REINDEXがクラスタの一部である、または必要についてのすべてでは何も言いません
誰もが明確に（つまり、公式ドキュメントへの何らかの参照を持っている）、CLUSTER後にREINDEXが必要かどうかを言うことができますか？
回答:
インデックスを再作成する必要はありませんCLUSTER。効果的にインデックスを作成するからです。
より具体的にはCLUSTER、ソーステーブルをロックしてから、ターゲットインデックスに従って順序付けられた新しいコピーを作成します。新しいコピーにインデックスを作成し、古いテーブルとインデックスを新しいものに置き換えます。
これはVACUUM FULL9.0以降でも当てはまることに注意してください。
CLUSTER肥大化することを示唆する議論を見てきたなら、CLUSTER9.0以前のように機能すると想定している人かもしれませんVACUUM FULL。古いVACUUM FULL実装によって引き起こされたインデックスの膨張に言及CLUSTERし、代替手段として提案する議論を見て誤解しているかもしれません。
これはドキュメントで暗示されています：
インデックス順にテーブルデータを含むテーブルの一時コピーが作成されます。テーブルの各インデックスの一時コピーも作成されます。したがって、少なくともテーブルサイズとインデックスサイズの合計に等しいディスク上の空き領域が必要です。
言っていないが、そうすべきであるのは、それらの一時コピーが元のテーブルを置き換えるということです。（大胆な鉱山）。
CLUSTERんではないでインデックスを書き換えて、実際のファイルの検査base/明確に新しい表示されますrelfilenode秒。まだ抱えていない問題を心配しているようです。
これにはa_horse_with_no_nameを使用しています。インデックスを再作成する必要はありません。ことのほかにCLUSTERドキュメントがそれを言及していない、我々はさらに相談することができREINDEX、ページをあまりにも：
REINDEXを使用するシナリオはいくつかあります。
インデックスが破損し、有効なデータが含まれなくなりました。理論上はこれが起こるべきではありませんが、実際にはソフトウェアのバグやハードウェアの障害によりインデックスが破損する可能性があります。REINDEXは回復方法を提供します。
インデックスは「肥大化」しており、多くの空または空に近いページが含まれています。これは、特定の一般的でないアクセスパターンの下で、PostgreSQLのBツリーインデックスで発生する可能性があります。REINDEXは、デッドページなしで新しいバージョンのインデックスを書き込むことにより、インデックスのスペース消費を削減する方法を提供します。詳細については、セクション23.2を参照してください。
インデックスのストレージパラメータ（fillfactorなど）を変更しましたが、変更が完全に有効になるようにします。
CONCURRENTLYオプションを使用したインデックスの構築が失敗し、「無効な」インデックスが残りました。このようなインデックスは役に立ちませんが、REINDEXを使用してインデックスを再構築すると便利です。REINDEXは同時ビルドを実行しないことに注意してください。実動を妨げることなく索引を作成するには、索引をドロップして、CREATE INDEX CONCURRENTLYコマンドを再発行する必要があります。
明らかに、CLUSTERこれらのケースのいずれにも該当しません。
そして、CLUSTERドキュメントには小さな文があります：
[クラスタリング中]テーブルの各インデックスの一時コピーも作成されます。
これは、テーブル自体と同様に、プロセス中にもインデックスの順序が変更されることを示唆しています。この方法では、インデックスの再作成が不要になります。
Recovering Disk Spaceセクションで参照を見つけました。
そのようなテーブルがあり、それが占有する余分なディスク領域を再利用する必要がある場合は、VACUUM FULL、またはCLUSTERまたはALTER TABLEのテーブル書き換えバリアントのいずれかを使用する必要があります。これらのコマンドは、テーブルの新しいコピー全体を書き換え、新しいインデックスを作成します。
私の意見では、すべての答えを分析する正しい方法は、クラスターの前にインデックスを再作成することです。ドキュメントでは、クラスターがインデックスの再作成を行うかどうか、およびインデックスのコピーのみを順序付けているかどうかを示していないため、インデックス付きインデックスの方がクラスター化されたテーブルが優れていると思います。その後、分析によってジョブが終了します。クラスターやインデックスの再構築でデッドタプルが解放されない限り、すべての前にバキュームがいっぱいになると役に立たないようです
CLUSTERをVACUUM FULL生成します-それの後に死者がいることはありません。古いコピーで使用されていたスペースは、操作の終了までに解放されます。
cluster行を再配置するため、とにかくインデックス情報を更新する必要があります。