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
はほとんどのヒープデータが順序づけられて、そこにあるインデックスが使用
されるため、速くなるはずです。