web-dev-qa-db-ja.com

データウェアハウスのDROP TABLE / TRUNCATEアプローチではVACUUM FULLが必要ですか

データウェアハウスを毎週更新しています。

TRUNCATE source_table1 
COPY source_table1 FROM [...]

...データのインポートと：

DROP TABLE IF EXISTS my_table
CREATE TABLE my_table AS SELECT [...]

テーブルの更新用。

ドキュメントが示唆するように、タプルのかなりのシェアが更新または削除された場合、VACUUMを実行する必要があるため、更新プロセスはVACUUM FULL [VERBOSE] ANALYZEで終了します。ここでは、すべてのテーブルで100％のシェアであるため、VACUUMを適用する必要があると合理的に考えました。

Verboseオプションの出力を見ると、すべてのテーブルVACUUMedから次のように、Postgresqlが行うことはあまりないようです。

INFO:  vacuuming "public.table345"
INFO:  "table345": found 0 removable, 9831703 nonremovable row versions in 62538 pages
DETAIL : 0 dead row versions cannot be removed yet.

逆にANALYZEは内部統計を更新するのに役立つ以上のものだと思います。ほとんどのテーブルのサイズは10〜100m行です。

しかし、その場合、本当にVACUUM FULLまたはVACUUMが本当に必要なのでしょうか。

（または、更新プロセス全体（DROP/CREATE TABLE AS）が正しい方法ではない可能性がありますか？）

postgresqlvacuumpostgresql-9.6
3
ant1j

TRUNCATE/COPYに関するポイント

WALレベルに応じて、WALがスキップされるため、TRUNCATEとCOPYを同じトランザクションでラップすることが速くなる可能性があります。 。さらに、CTASは常にほとんどのWALをスキップします。

最小限のレベルでは、一部の一括操作のWALロギングを安全にスキップできるため、これらの操作を大幅に高速化できます（セクション14.4.7を参照）。この最適化を適用できる操作には、 source が含まれます

  • CREATE TABLE AS
  • インデックスを作成
  • 集まる
  • 同じトランザクションで作成または切り捨てられたテーブルへのコピー
    BEGIN;
      TRUNCATE source_table1 
      COPY source_table1 FROM [...]
    COMMIT;

VACUUM FULLの発行

  1. 新しいテーブルでVACUUM FULLを実行する必要はありません。これらのトランザクションではテーブルがすでに新しいため、FULLのようにテーブルを書き換える必要はありません。 VACUUMが作用する移動可能な行がないため、VACUUMする必要もありません。 VACUUM FULL VERBOSEを実行すると、削除できるものがなく、デッド行が削除されていないことがわかります。 VACUUM FULLは次の場合に役立ちます

    1. 一時テーブルを使用してINSERTSをステージングし、それらをバッチでダーティテーブルに追加しています。その後、プロセスの最後に成果を上げることができます。
    2. UPDATEは新しい行を生成するため、UPDATEを大きなバッチで実行しています。古い行を後でデッドとしてマークするようにVACUUMに強制するためです。

  2. 単純なANALYZEで問題なく動作します。これにより、テーブルのstatisticsが更新されます。

1
Evan Carroll