PostgreSQL 10主库启用hot_standby_feedback的额外性能影响咨询

嗨，针对你的问题——开启hot_standby_feedback后主库会不会因为判断延迟清理产生显著性能开销，我结合实际运维经验和PG的底层逻辑给你拆解下：

• 主库的额外性能开销其实非常有限
  PostgreSQL主库在处理VACUUM或者自动清理（autovacuum）的时候，原本就需要跟踪当前集群内的活跃事务，以此判断哪些元组可以安全清理。开启hot_standby_feedback后，主库只是多接收了备库发送的活跃事务快照信息，把备库上未结束的读事务也纳入到“不能清理”的事务列表中。
  这个过程的额外开销极小：备库发送的只是一组事务ID集合，数据量非常小；主库处理这些信息也只是简单的快照合并，没有复杂计算或IO操作。在绝大多数生产场景下，这个开销完全可以忽略，不会对主库性能造成明显影响。

• 真正的风险是存储膨胀，而非主库性能开销
  你已经提到hot_standby_feedback会导致主库延迟清理，这才是需要重点关注的问题。比如如果备库上有长时间运行的读查询（比如跑几个小时的报表），主库会一直保留该查询依赖的旧元组，直到备库查询结束。如果这类长查询频繁出现，主库的表膨胀速度会显著加快，反而会间接影响性能——比如磁盘IO负载上升、索引扫描效率下降等。

• 给你的实际运维建议

  • 如果备库上的读查询都是短耗时的业务查询，开启hot_standby_feedback是完全可行的，既不会带来明显性能开销，还能避免备库因主库清理元组而出现查询报错（比如常见的“could not access status of transaction XXX”）。
  • 如果备库存在长耗时查询，建议不要开启该功能，而是考虑替代方案：比如设置max_standby_streaming_delay让备库在延迟过大时暂停复制，或者将长查询迁移到专门的只读副本（比如基于逻辑复制、定时刷新的副本，而非流复制热备）。
  • 无论是否开启该功能，都要定期监控主库的表膨胀率（可以使用pgstattuple扩展来查看），及时通过VACUUM FULL或者分区重构等方式处理严重膨胀的表。

内容的提问来源于stack exchange，提问作者dor.elmaliach