長時間実行される分析クエリのスタンバイワークロードの場合、hot_standby_feedbackをオンにするか、max_standby _ * _ delay設定を-1に設定する方が良いですか？
長時間実行されるクエリが一般的であるBI/Analytics専用のホットスタンバイサーバーを起動する場合、hot_standby_feedbackをオンにするか、max_standby_*_delay設定を-1に設定する方が良いですか？
私の理解では、hot_standby_feedbackは、max_standby_*_delay設定によってVACUUMがマスターで開始できるようにして、スタンバイで同様に安全にできるまで、マスターがVACUUMのようなことを行えないようにします。実行時間の長いクエリと競合する可能性のあるバキュームクリーンアップの適用を待機します。
さらに、hot_standby_feedbackの docs状態 ：
スタンバイクエリのキャンセルの数が受け入れられないことが判明した場合、修正の可能性があります。最初のオプションは、パラメータhot_standby_feedbackを設定することです。これにより、VACUUMが最近死んだ行を削除することがなくなり、クリーンアップの競合が発生しなくなります。これを行う場合は、プライマリのデッド行のクリーンアップが遅延し、望ましくないテーブルの膨張が発生する可能性があることに注意してください。ただし、クリーンアップの状況は、スタンバイクエリがプライマリサーバーで直接実行されていた場合よりも悪くはなく、実行をスタンバイにオフロードすることの利点が引き続き得られます。
そしてmax_standby_*_delayのドキュメントの状態：
スタンバイサーバーが意思決定支援クエリの追加サーバーとして機能している場合、最大遅延値を何時間にも設定できます。-1にしても、クエリが完了するまで永久に待機することになります。
どちらがより良いのか、それぞれの長所と短所はどのようなものなのかは、まだはっきりしていません。
hot_standby_feedbackオンの場合、バキュームは引き続き実行できますが、バキューム処理されるタプルを後でバキューム処理に遅らせる必要があるため、効果が低下します。私が知っている唯一の本当の欠点は、膨らみの増加です。これがどれほどのマイナス面であるかは、使用方法に完全に依存します。最悪のケースは、ワークキューテーブルのように、データベースに小さく、集中的に更新されるテーブルがある場合です。それらは非常に肥大化する可能性があります。そのようなテーブルがない場合は、おそらく問題はないでしょう。
Max_standby _ * _ delayの問題は、スタンバイで実行されている他のクエリも潜在的に大量にその地平線を保持していること、およびスタンバイを十分に長く保持すると、蓄積された未再生のWALファイルがハードドライブをいっぱいにすることです。そしてあなたはスタンバイを失うでしょう。
hot_standby_feedbackはプライマリサーバーのアクティビティに影響しますが、max_standby_*_delayはスタンバイサーバーのアクティビティに影響します。
hot_standby_feedbackの短所は明らかです。競合が発生している間、Primaryはデッドタプルを削除できません。
max_standby_*_delayはスタンバイサーバー用であり、プライマリのアクティビティには影響しません。これは、これらのパラメータの長所の1つです。それらの短所は次のとおりです。スタンバイで競合が発生すると、スタンバイはWALログの再生をmax_standby_*_delayまで中断します。したがって、クエリによって1つの競合が発生した場合、後続のクエリは古いデータ（競合が発生する直前のデータベースのスナップショット）を読み取り、スタンバイがWALの再生を一時停止するため、最新のデータを読み取ることができません。
スタンバイでクエリを1つだけ実行する場合、-1をmax_standby _ * _ delayに設定できると思います。