CLUSTER は、indexname で指定されたインデックスに基づいた、tablename で指定されたテーブルをクラスタ構成するように、PostgreSQL に指示します。インデックスは前もって tablename で定義されていなければなりません。
テーブルがクラスタ構成されると、インデックス情報に基づいて物理的に再序列されます。 クラスタ構成は、一回限りの操作です。 クラスタ構成後にそのテーブルが更新されても、変更はクラスタ構成されません。 つまり、新規もしくは更新されたタプルを、インデックス順に保管することは行ないません。 インデックス順に保管したい場合、コマンドを再度入力し、定期的に再クラスタ構成を行います。
あるテーブル内の1つの行をランダムにアクセスする場合、ヒープテーブル内のデータの実際の順序は重要でありません。とはいえ、テーブル内の特定のデータにより頻繁にアクセスする場合で、それらのデータをグループ化しているインデックスが存在するときは、CLUSTER を使うことによる利益を享受することができます。
CLUSTER が役立つこれ以外の場合は、テーブルからいくつかの行を抽出するのにインデックスを使用するときです。テーブルからインデックスの値の範囲や、一致する複数の行を保有する1つのインデックスの値などを要求する場合、インデックスがひとたび最初に一致する行に対するヒープページを認識すると、一致するすべての他の行もおそらく同じヒープページに存在することになるので、CLUSTER はディスクアクセスを減らして問い合わせ処理の速度を速めます。
クラスタ処理の間、テーブルデータがインデックス順に並んだ、テーブルの一時コピーが作成されます。 同様に、テーブルの各インデックスの一時コピーも作成されます。 したがって、ディスクには、少なくともテーブルとインデックスの合計サイズと同じ容量の空きスペースが必要です。
CLUSTER 処理では、テーブルの GRANT、継承、インデックス、外部キー、およびその他の付属情報が保持されます。
オプティマイザによってテーブルの順序付けに関する統計情報が記録されているため、新しくクラスタ構成されたテーブルに ANALYZE を実行することが推奨されます。 そうしないと、オプティマイザが問い合わせ計画を適切に選択できない可能性があります。
データをクラスタ構成する別の方法があります。 CLUSTER コマンドを使用して、指定したインデックス順で元のテーブルを再度順序付けする方法です。行はインデックスの順序におけるヒープから取り出され、また、ヒープテーブルが順序付けらていない場合、項目はでたらめの順序のページ上に存在するため、移動する行毎に 1 つのディスクページが抽出されることになります。従って、巨大なテーブルでは低速になることがあります。 ( PostgreSQL にはキャッシュがありますが、大きなテーブルの大多数はキャッシュに収まり切れません。) テーブルをクラスタ構成するもう 1 つの方法は、以下のような SQL 文を使用するものです。
SELECT columnlist INTO TABLE newtable
FROM table ORDER BY columnlist
この SQL 文では、PostgreSQL のソート用のコードを ORDER BY 句で使用し、必要な順序付けをします。この方法は通常、順序付けられていないデータに対するインデックススキャンよりも処理時間がずっと短くなります。その後、古いテーブルを削除し、ALTER TABLE...RENAME で newtable を前の名前に書き換えてから、テーブルのインデックスを再生成しても構いません。 しかし、この方法では、テーブルの OID、制約、外部キー関係、与えられた権限、およびその他の付属情報を保持しません。これらの付属情報は、手動で再作成する必要があります。