通常のVACUUM ANALYZEは9.1でも引き続き推奨されますか？

UbuntuでPostgreSQL 9.1を使用しています。スケジュールはVACUUM ANALYZEまだ推奨されていますか、それとも自動バキュームですべてのニーズに対応できますか？

答えが「依存する」の場合：

• 大きなデータベースがあります（30 GiBの圧縮ダンプサイズ、200 GiBのデータディレクトリ）
• データベースにETLを実行し、週に300万行近くをインポートします
• 最も頻繁に変更されるテーブルはすべてマスターテーブルから継承され、マスターテーブルにはデータがありません（データは週ごとに分割されます）
• 時間ごとのロールアップを作成し、そこから毎日、毎週、毎月のレポートを作成します

スケジュールVACUUM ANALYZEがレポートに影響しているので、私は尋ねています。5時間以上実行されますが、通常のデータベースインポートに影響を与えていたため、今週2回停止する必要がありました。check_postgresデータベースの大きな膨張を報告しないため、それは実際には問題ではありません。

ドキュメントから、autovacuumはトランザクションIDのラップアラウンドも処理する必要があります。質問が立っています：私はまだ必要VACUUM ANALYZEですか？

VACUUMは、非一時テーブルの更新または削除された行でのみ必要です。明らかに多くのINSERTを行っていますが、説明からも多くのUPDATEまたはDELETEを行っていることは明らかではありません。

これらの操作は、pg_stat_all_tablesビューを使用して、特に列n_tup_updとn_tup_del列で追跡できます。また、さらに重要なことに、n_dead_tupテーブルごとに、バキューム処理が必要な行の量を示す列があります。（統計の収集に関連する機能とビューについては、ドキュメントの統計の監視をご覧ください）。

あなたの場合の可能な戦略は、スケジュールされたVACUUMを抑制し、このビューに注目し、どのテーブルがn_dead_tup大幅に上昇しているかをチェックすることです。次に、これらのテーブルにのみ積極的なVACUUMを適用します。行が削除も更新もされない大きなテーブルがあり、小さなテーブルでのみ積極的なVACUUMが本当に必要な場合、これは勝利になります。

ただし、常に最新の統計を取得するには、オプティマイザーのANALYZEを実行し続けます。

あなたの質問には何のautovacuum面倒も見ないでしょう。それはあなたの執筆活動のパターンに大きく依存します。毎週300万の新しい行に言及しますが、INSERT（またはCOPY）通常、テーブルとインデックスの膨張を作成しません。（列統計、可視性マップ、およびいくつかのマイナーなジョブautovacuumのみを処理する必要があります）。そして、特にランダムな行を対象とする場合、テーブルとインデックスの肥大化の主な原因です。私はあなたの質問にはそれを見ていません。UPDATEDELETE

autovacuumPostgres 9.1以降で大きな進歩を遂げ、素晴らしい仕事をしています。autovacuum設定を見てみましょう。バキューム処理が作業負荷を妨げる傾向がある場合は、「コストベースのバキューム遅延」も参照してください。手動バキュームはまれな例外です。

randomがたくさんある場合は、を100未満UPDATEに設定しFILLFACTORて、HOTの更新をすぐに許可し、の必要性を減らすことができVACUUMます。HOTアップデートの詳細：

• 更新ステートメントの冗長データ

また、一時テーブルには手動VACUUM＆が必要ANALYZEです。私はマニュアルCREATE TABLEを引用します：

自動バキュームデーモンはアクセスできないため、真空または一時テーブルを分析することはできません。このため、セッションSQLコマンドを介して適切なバキュームおよび分析操作を実行する必要があります。たとえば、一時テーブルを複雑なクエリで使用する場合はANALYZE、一時テーブルにデータを入力してから実行するのが賢明です。

データベース全体で実行するよりも自動機能を使用するのが最適であることに同意しますが、ほとんどの場合、テーブルごとのチューニングが必要です。

バキュームと分析を結びつけるpostgresの設計選択にはまったく同意しません。多くの挿入/更新を行うが、ほとんど削除しないと分析が完了せず、パフォーマンスが低下し始めるいくつかのインスタンスを見てきました。

解決策は、頻繁に使用され、大きなクエリの対象となるテーブルに移動し、それらのテーブルの自動分析設定を、1回または1日おきに分析される場所に設定することです。

GUIの[自動バキューム]タブでテーブルごとの設定にアクセスでき、そこに分析設定が表示されます。この設定は、バキュームとは別に設定できます。

設定はreloptionsテーブルになり、クエリで確認できます

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

アグレッシブ分析のサンプル値は

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

テーブルが最後に自動分析されたクエリをいつ取得したかを確認するには

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;