Postgresのautovacuumはいつ実行されますか
古いバージョンのPostgres（8.4.20）を使用しています。テーブルのデータを削除または更新したクエリのディスク領域を解放するために、自動バキュームプロセスが頻繁に実行されることを知っています。頻繁に削除または更新されないデータベースがあります。
そのようなデータベースで自動バキュームを処理するのにかかる時間とメモリは少なくなりますか、それともデータベース内のオブジェクトのサイズと数にのみ依存しますか？
まず最初に— 8.4はサポートされなくなったため、アップグレードを検討してください。
自動バキューム設定は 文書化 です。
when autovacuumが影響を与える設定に注目しましょう。ご存知のように、このプロセスはテーブルのバキュームと分析の両方を担当します。
ANALYZEの頻度に影響する設定の1つは_autovacuum_analyze_threshold_です。マニュアルから読み取れるように、このパラメーターは、ANALYZEをトリガーするために変更する必要がある行の最小量を指定します。これは小さなテーブルには適していますが、大きなテーブルやアクティビティの多いテーブルでは頻繁に分析する方法につながります。これを回避するために、別のパラメーター、つまり_autovacuum_analyze_scale_factor_が存在します。 ANALYZEが起動するかどうかを確認するために、しきい値に追加するテーブルの割合を指定します。
たとえば、10,000行のテーブルがあり、そのうち200行が変更されたとします。
- _
autovacuum_analyze_threshold_は、デフォルトの_50_を超えていることを通知します。 - _
autovacuum_analyze_scale_factor_（デフォルトは_0.1_）に基づいて分数を計算し、これにより1000行が得られます。 - したがって、計算された合計しきい値は_
1050_です。 - 200は1050よりも小さいため、
ANALYZEは開始されません（変更が完了するのを待ちます）。
VACCUMの場合、完全に同様の動作をする別のパラメーターのペアがあります：_autovacuum_vacuum_threshold_および_autovacuum_vacuum_scale_factor_。ただし、バキュームのデフォルトのスケールは_0.2_または20％です。
推測できるように、テーブルが大きくなるほど、自動バキュームのトリガーにかかる時間が長くなります。したがって、大きなテーブル（通常は100万行以上）の場合は、これらの設定を調整することを強くお勧めします。 ALTER TABLE ... SET ( storage_parameter = ... ) 構文を使用して、テーブルごとにこれを行うことができます。
_*_scale_factor_を0に設定し、より大きなテーブルのしきい値のみを増やすのは魅力的です。それでも、係数を小さく、ゼロ以外の値に保つことをお勧めします。アクティビティが多いテーブルでは、100,000行の変更が頻繁に発生し、不要な自動バキュームが発生する可能性があるためです。 pgsql-performanceリストの this thread を参照してください。