CLUSTERは、 indexname で指定されたインデックスにほぼ基づいた、 tablenameで指定されたテーブルをクラスタ構成するように PostgreSQL に指示します。インデックスは前もって tablename で定義されていなければなりません。
テーブルがクラスタ構成されると、インデックス情報に基づいて物理的に再序列されます。クラスタ構成は静的です。別の表現をすると、テーブルが更新されても、その変更はクラスタ構成されません。新しいインスタンスやクラスタ構成済みのタプルへの更新は保存されません。保存したい場合、コマンドを再度入力し手作業で再クラスタ構成を行います。
実際にはテーブルはインデックスの順序で一時テーブルにコピーされ、そして最初の名前に戻されます。この理由によって、すべての与えられた権限と他のインデックスはクラスタ構成が行われたときに失われます。
あるテーブル内の1つの行をランダムにアクセスする場合、ヒープテーブル内のデータの実際の順序は重要でありません。とはいえ、テーブル内の特定のデータにより頻繁にアクセスする場合で、それらのデータをグループ化しているインデックスが存在するときは、CLUSTER を使うことによる利益を享受することができます。
CLUSTER が役立つこれ以外の場合は、テーブルからいくつかの行を抽出するのにインデックスを使用するときです。テーブルからインデックスの値の範囲や、一致する複数の行を保有する1つのインデックスの値などを要求する場合、インデックスがひとたび最初に一致する行に対するヒープページを認識すると、一致するすべての他の行もおそらく同じヒープページに存在することになるので、CLUSTER はディスクアクセスを減らして問い合わせ処理の速度を速めます。
データをクラスタ構成するには 2 つの方法があります。その 1 つは、 CLUSTER コマンドでオリジナルのテーブルを指定したインデックスの順序によって再順序付けをする方法です。行はインデックスの順序におけるヒープから取り出され、また、ヒープテーブルが順序付けらていない場合、項目はでたらめの順序のページ上に存在するため、移動する行毎に 1 つのディスクページが抽出されることになります。従って、巨大なテーブルでは低速になることがあります。PostgreSQLにはキャッシュがありますが、大きなテーブルの大多数はキャッシュに収まり切れません。
データをクラスタ構成するもう 1 つの方法は次の SQL 文を実行することです。
SELECT columnlist INTO TABLE newtable
FROM table ORDER BY columnlist
これは PostgreSQL の ORDER BY のソートのコードをインデックスに一致させるために使用するので、順序付けられていないデータに対して高速です。その後、古いテーブルを削除し、 ALTER TABLE...RENAME で newtable を前の名前に書き換えてから、テーブルのインデックスを再生成しても構いません。 OID が保存されないのが唯一の問題点です。その後、 CLUSTER はほとんどのヒープデータが順序付けられて、そこにあるインデックスが使用されるため、速くなるはずです。