他のバージョンの文書10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

CLUSTER

Name

CLUSTER  --  インデックスに従ったテーブルのクラスタ化

Synopsis

CLUSTER indexname ON tablename

入力

indexname

インデックスの名前です。

table

テーブルの名前です。

出力

CLUSTER

クラスタ構成が正常に終了しました。

ERROR: relation <tablerelation_number> inherits "table"

ERROR: Relation table does not exist!

説明

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...RENAMEnewtable を前の名前に書き換えてから、テーブルのインデックスを再生成しても構いません。 OID が保存されないのが唯一の問題点です。その後、 CLUSTER はほとんどのヒープデータが順序付けられて、そこにあるインデックスが使用されるため、速くなるはずです。

使用方法

給与属性に基づいて従業員リレーションをクラスタ構成するには以下のようにします。

CLUSTER emp_ind ON emp;

互換性

SQL92

SQL92にはCLUSTER 文はありません。