PostgreSQL 15 移除 Stats Collector 后台进程

PostgreSQL 15 作为重要版本更新，带来了多项架构优化，其中最引人关注的变更之一是正式移除了传统的 Stats Collector 后台进程。不少开发者在试用 PostgreSQL 15 时会发现，数据库启动后不再出现postgres: stats collector相关进程，这一变更并非简单的功能删减，而是 PostgreSQL 对统计信息收集机制的彻底重构，旨在解决旧架构的性能瓶颈。

一、为什么要移除 Stats Collector？

Stats Collector 是 PostgreSQL 早期版本中负责收集数据库运行统计信息的核心进程，主要用于收集表访问频次、索引使用情况、连接数等关键数据，为查询优化器提供决策依据。但随着数据库规模扩大和并发量提升，该进程逐渐暴露出明显局限：

 

1. 性能瓶颈：Stats Collector 采用单进程设计，所有统计数据的收集、存储均由其独立处理，高并发场景下易出现 CPU 或 I/O 阻塞；
2. 数据延迟：统计信息通过共享内存队列异步传递给 Stats Collector，存在一定延迟，可能导致查询优化器基于 “过时数据” 生成执行计划；
3. 资源占用：即使数据库处于低负载状态，Stats Collector 仍需持续运行以维护统计信息，造成不必要的系统资源消耗；
4. 稳定性风险：极端情况下，Stats Collector 进程崩溃可能导致数据库统计信息丢失，影响查询优化效果。

 

为解决这些问题，PostgreSQL 15 放弃了独立进程的设计，转而采用更高效的内置统计收集机制。

二、新统计收集机制：轻量、实时、无额外进程

PostgreSQL 15 用共享内存 + 轻量级内置逻辑替代了原有的 Stats Collector 进程，核心优化如下：

 

1. 分布式收集：统计信息不再依赖独立进程，而是由数据库核心进程（如后端连接进程、WAL 写入进程）在执行业务操作时 “顺带” 收集，避免单进程瓶颈；
2. 实时写入共享内存：收集到的统计数据直接写入专用共享内存区域，无需通过队列异步传递，数据延迟几乎为零；
3. 按需持久化：统计信息默认存储在共享内存中，仅在数据库关闭或特定触发条件下（如共享内存达到阈值）持久化到磁盘，减少 I/O 开销；
4. 兼容原有功能：虽然底层实现变更，但统计信息的使用方式完全兼容旧版本，pg_stat_*系列系统视图（如pg_stat_user_tables、pg_stat_index）仍可正常查询，无需修改应用代码。

三、用户适配建议：零成本迁移，性能自动提升

Stats Collector 的移除对用户而言几乎是 “无感变更”，无需复杂适配即可平滑升级，仅需关注以下两点：

 

1. 配置项兼容：原与 Stats Collector 相关的配置参数（如stats_collector、stats_queue_size）在 PostgreSQL 15 中已失效，升级后可从postgresql.conf中删除，避免冗余配置；
2. 性能监控调整：若此前通过监控 Stats Collector 进程状态判断数据库健康度，升级后需改为监控pg_stat_*视图的数据更新频率，或通过pg_stat_activity查看核心进程状态；
3. 升级注意事项：从低版本升级到 PostgreSQL 15 时，数据库会自动迁移历史统计数据，无需手动干预，升级后首次启动即可享受新机制带来的性能提升。

四、变更意义：为大规模场景保驾护航

此次 Stats Collector 的移除，是 PostgreSQL 向 “高性能、高并发、低资源消耗” 方向演进的重要一步。新机制在保持统计信息准确性的前提下，大幅降低了系统开销，尤其适合以下场景：

 

• 高并发 OLTP 系统（如电商交易、支付系统）：减少进程间通信开销，提升数据库响应速度；
• 大规模数据仓库：实时统计信息让查询优化器更精准，复杂查询执行效率提升明显；
• 资源受限环境（如容器、云服务器）：无需额外进程占用 CPU / 内存，资源利用率更高。