Postgresがパフォーマンスを自動分析
Postgresql 9.4では、更新や削除は一切行わず、挿入と選択のみを行うテーブルがあります。したがって、自動バキュームが行われることはありませんが、自動分析は行われます。そのため、100秒以上かかることがあります。その100秒間とその後のかなりの時間の間、DBのパフォーマンスはひどいものになり、私のアプリは、通常の2ミリ秒の範囲ではなく、40〜150秒の範囲でデータベースの応答時間を報告します。
自動バキュームを無効にするべきではないといつも聞いていましたが、このテーブルにautovaccum_enabled = falseを設定すると、dbはより確実に実行されます。このテーブルで有効にする理由はありますか？クエリプランナーは、更新や削除を取得しないテーブルで自動分析を実行しないと、最終的に影響を受けますか？これを解決するより良い方法はありますか？
編集：分析をより頻繁に行うために、このテーブルのautovacuum_analyze_thresholdおよびautovacuum_analyze_scale_factorを潜在的に変更する方が良いでしょうか？
あなたの最良の選択肢は、お気に入りのOSスケジューリングツールを使用してANALYZE <table>明示的かつ先制的に、選択した時間に、たとえば午前3時に。
PostgreSQLの自動バキュームと自動分析は、アクティビティカウンターによって駆動されます。これには不幸な影響があり、アクティビティカウンターがしきい値を超えるのは、ほとんどの場合、データベースが最もアクティブなときに正確である可能性があります。つまり、メンテナンスタスクを実行したくない場合です。オフピーク時にタスクをプリエンプティブに実行することにより、アクティビティカウンターをリセットします。これにより、自動バージョンで行うべき作業がほとんど見つかりません。しかし、何かがうまくいかない場合でも、彼らはあなたのベーコンを救うためにまだそこにいます。
クエリプランナーは、更新や削除を取得しないテーブルで自動分析を実行しないと、最終的に影響を受けますか？
これはあなたが提供する情報では答えられません。たとえば、そのテーブルが一意のインデックスを介して単一行のルックアップしか取得しない場合、古い統計が問題になることはほとんどありません。複雑な分析クエリを取得する場合、それははるかに問題になる可能性があります。