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