CLUSTERのパフォーマンスへの影響

Postgres 9.2データベースを最適化して、日付制限のあるクエリを高速化しようとしています。

私はtimestamp列を持っていますが、たいていはいつか尋ねているのでtimestamp、date解析するためのインデックスを作成しました：

CREATE INDEX foo_my_timestamp_idx
ON foo
USING btree
((my_timestamp::date) DESC);

次に、パフォーマンスを向上させるために、CLUSTER foo上記のインデックスを使用してテーブルを作成します。

CLUSTER foo USING foo_my_timestamp_idx;

SQL-CLUSTERのマニュアルによると、テーブル

インデックス情報に基づいて物理的に並べ替えられます

テーブルのPKを使用する他のクエリのパフォーマンスに影響があるかどうかを知ります（としましょうid_foo）。欠点はありますか？

はい、欠点がある可能性があります。別のクエリが日付で決定されない別のデータセグメントを調べる場合、行がより多くのデータページに分散されていると、パフォーマンスに影響する可能性があります。最初のクエリの利益とまったく同じです。それはあなたの質問にない情報に完全に依存しています。

テーブルのPKを使用する他のクエリ（id_fooとしましょう）

それは何でもかまいません。それはあなたが持っているものとあなたが正確に何をクエリするかに依存します。単一の行のクエリはどちらの方法でも影響を受けませんが、複数の行は影響を受ける可能性があります。

のCLUSTERように元の状態でテーブルを書き換えるVACUUM FULL（デッドタプルを削除する、テーブルの物理サイズを圧縮する、インデックスを書き換える）ことに注意してください。したがって、並べ替え順序とは関係なく、読み取りパフォーマンスにすぐにプラスの影響が出る可能性があります。（と同じようにVACUUM FULL。）
その後CLUSTER、VACUUMテーブルでプレーンを実行して可視性マップを更新することもできます。これにより、インデックスのみのスキャンが可能になる場合があります。

CLUSTER書き込み頻度とともに縮小するすべての利点。

あなたがテーブルに多くの更新を持っている場合にも、CLUSTER実際にできる傷 HOTのために、「ウィグルの部屋」を除去することにより、書き込み性能は、同じデータページに更新します。FILLFACTOR100未満の設定でその影響に対抗できる場合があります。ここでも、更新された行の局所性などに依存します。

関連：

• 日付によるインデックスの最適化

いずれにせよ、私はおそらくでインデックスを作成してクラスター化せずmy_timestamp::date、my_timestamp直接オンにします。何も失わず、何かが得られた。キャストは非常に安価ですが、まったくキャストしない方が安いです。インデックスはより多くのクエリをサポートできます。

CREATE INDEX foo_my_timestamp_idx ON foo (my_timestamp);

にもかかわらず、dateディスク上の唯一の4バイトを占有し、timestamp8つのバイトを占め、差は通常、あなたのケースのためのアライメントパディングに失われた、との両方のインデックスが持っている、正確に同じ大きさで。

式インデックスに起因する同じ日の複数の行の順序は任意です。それでも2つの同じタイムスタンプが存在する可能性がありますが、通常はほとんどあり得ない6つの小数桁があります。それとは別に、行の確定的な順序を取得します。これにはさまざまな利点があります。

DESCPostgresは実質的に高速で前方にインデックスを逆方向に読み取ることができるため、キーワードも省略しました。（ただし、マルチカラムインデックスではソート順が重要です！）詳細：

• タイムスタンプの範囲（2列）でのクエリの最適化

の代わりに：

SELECT * FROM foo
WHERE my_timestamp::date = '2016-07-25';

あなたは今使うでしょう：

SELECT * FROM foo
WHERE  my_timestamp >= '2016-07-25'  -- this is a timestamp literal now
WHERE  my_timestamp <  '2016-07-26';

同じパフォーマンス。

あなたは、列の時間コンポーネントを必要としない場合は、すべてで、に列を変換しますdate...

ロールバックする方法はCLUSTER？

CLUSTER単一のテーブルではROLLBACK、トランザクションがコミットされていない限り、他の通常のコマンドと同様にロールバックできます。

しかし、私はマニュアルを引用します：

CLUSTERパラメータを指定しないと、呼び出し元のユーザーが所有する現在のデータベース内の以前にクラスタ化されたすべてのテーブル、またはスーパーユーザーから呼び出された場合はそのようなすべてのテーブルが再クラスタ化されます。この形式はCLUSTER、トランザクションブロック内では実行できません。

いつでもCLUSTER別のインデックスで実行して、行の物理的な順序をもう一度変更できます。