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