CLUSTER は、indexname で指定されたインデックスに基づいた、tablename で指定されたテーブルをクラスタ構成するように、PostgreSQL に指示します。 インデックスは前もって tablename で定義されていなければなりません。
テーブルがクラスタ構成されると、インデックス情報に基づいて物理的に再序列されます。 クラスタ構成は、一回限りの操作です。 クラスタ構成後にそのテーブルが更新されても、変更はクラスタ構成されません。 つまり、新規もしくは更新されたタプルを、インデックス順に保管することは行ないません。 インデックス順に保管したい場合、コマンドを再度入力し、定期的に再クラスタ構成を行います。
テーブルがクラスタ構成されると、PostgreSQL はどのインデックスでクラスタ構成されたかを記録します。 CLUSTER tablename という形式で、以前にクラスタ構成された時と同じインデックスを使用してテーブルをクラスタ構成します。
パラメータが無い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、制約、外部キー関係、与えられた権限、およびその他の付属情報を保持しません。これらの付属情報は、手動で再作成する必要があります。