PostgreSQL 15: stats collector进程优化掉了

来源：这里教程网时间：2026-03-14 20:38:10 作者：

PostgreSQL 15: stats collector进程优化掉了 PG15对统计进行了重大改进。将stats collector进程优化掉了，不再将统计数据放入临时文件中，而是放到共享内存中，在shutdown前由checkpoint进程将其持久化，启动时由startup进程将其加载。减少了IO和进程间通信，从而改进性能。

正文

尝试使用 PG15的用户都会发现有一个后台进程消失了：

postgres    1710       1  0 04:03 ?        00:00:00 /usr/pgsql-15/bin/postmaster -D /var/lib/pgsql/15/data/
postgres    1711    1710  0 04:03 ?        00:00:00 postgres: logger 
postgres    1712    1710  0 04:03 ?        00:00:00 postgres: checkpointer 
postgres    1713    1710  0 04:03 ?        00:00:00 postgres: background writer 
postgres    1715    1710  0 04:03 ?        00:00:00 postgres: walwriter 
postgres    1716    1710  0 04:03 ?        00:00:00 postgres: autovacuum launcher 
postgres    1717    1710  0 04:03 ?        00:00:00 postgres: logical replication launcher

PG14及其之前的版本：

postgres    1751       1  0 04:04 ?        00:00:00 /usr/pgsql-14/bin/postmaster -D /var/lib/pgsql/14/data/
postgres    1752    1751  0 04:04 ?        00:00:00 postgres: logger 
postgres    1754    1751  0 04:04 ?        00:00:00 postgres: checkpointer 
postgres    1755    1751  0 04:04 ?        00:00:00 postgres: background writer 
postgres    1756    1751  0 04:04 ?        00:00:00 postgres: walwriter 
postgres    1757    1751  0 04:04 ?        00:00:00 postgres: autovacuum launcher 
postgres    1758    1751  0 04:04 ?        00:00:00 postgres: stats collector 
postgres    1759    1751  0 04:04 ?        00:00:00 postgres: logical replication launcher

是的， “stats collector”消失了。主要瓶颈一去不复返了。

Stats collector进程作用？

新手用户可能想知道这个进程是什么？为什么 PG14及之前版本需要。有一些用户可能还会和对用于查询计划的表级统计信息采集（ANALYZE）感到迷惑。但这是不同的。PG跟踪每个进程的所有活动以获得累积统计信息，例如扫描表或索引的次数，或者最后一次vacuum或自动vacuum在表上的运行时间，或者自动vacuum在表上运行次数。所有信息统计收集的数据可以通过不同的pg_stat_*视图获得。

有什么问题？

会话的每个后台进程都是一个独立的 PG进程，采集统计信息和传输不是一个简单的任务。每个后台进程将他们的活动信息发送给单独的“stats collector”进程。通过UDP包进行通信。这种方法有很多问题，不是一个可扩展的模型。用户经常报告不同类型的问题，如1）过时的统计信息，2）stats collector未运行，3）autovacuum无法工作/启动等。如果 stats collector在某一个机器上发生问题，很难解释理解出了什么问题。 Stats collector另一个缺点是它引起的IO。如果启用DEBUG级别2，可以在日志中看到：

2022-08-22 03:49:57.153 UTC [736] DEBUG:  received inquiry for database 0
2022-08-22 03:49:57.153 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/global.stat"
2022-08-22 03:49:57.153 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/db_0.stat"
2022-08-22 03:49:57.168 UTC [1278] DEBUG:  autovacuum: processing database "postgres"
2022-08-22 03:49:57.168 UTC [736] DEBUG:  received inquiry for database 13881
2022-08-22 03:49:57.168 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/global.stat"
2022-08-22 03:49:57.168 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/db_13881.stat"
2022-08-22 03:49:57.169 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/db_0.stat"

可能导致数据目录所在的挂载点产生大量 IO。由参数stats_temp_directory控制，许多系统上将pg_stat_tmp位于数据目录中。在ubuntu/debian上位于/var/run/postgresql，例如：

postgres=# show stats_temp_directory ;
          stats_temp_directory           
-----------------------------------------
 /var/run/postgresql/14-main.pg_stat_tmp
(1 row)

PG15新功能

现在，统计信息不再使用文件和文件系统，而是使用动态共享内存 。可以参考 Andres Freund的commit摘要：以前， stats collector通过UDP接收统计更新，并通过定期将统计数据写入临时文件来共享统计数据。这些文件可以达到数十兆字节，冰箱每秒最多写入2次。这就一再阻止我们添加其他有用的统计数据。现在统计数据存储在共享内存。 variable-numbered对象统计信息存储在以dshash哈希表中（动态共享内存）。Fixed-numbered统计存储在普通共享内存中。 Pgstat.c的头文件中有架构的概述。Stats collector不再需要了，可以移除。利用事务统计丢掉 infrastructure（之前commit统计条目引入）不能再泄漏。之前通过pg_stat_vacuum_stat()删除泄漏的统计（被[auto-]vacuum调用）。在有许多小表的系统中pgstat_vacuum_stat()代价非常昂贵。现在对于删除的对象，副本删除统计信息条目，当从一个干净的 shut down副本开始就不再需要进行统计重置。很明显， stats_temp_directory参数弃用了。我们不再需要pg_stat_tmp目录。但是，保留这个目录不会破坏pg_stat_statements类似的插件使用。他们依赖于这个目录。例如，我们加载pg_stat_statements库，目录中会出现一个文件：

$ ls pg_stat_tmp/
pgss_query_texts.stat

新架构中，大多数统计更新首先在每个进程中累积为 “待处理”（每个后端都有一个本地哈希表）。“待定”是指他们已累积，但尚未提交到共享统计系统。稍后会在提交或超时后刷新到共享内存。由于统计数据会在有人尝试阅读时同时更新。因此就出现了读取一致性问题。所以 PG15引入了一个新参数stats_fetch_consistency，可以取值none，cache或snapshot。 “none”是最高效的，但不会提供一致性读。“cache”确保字段能够重复访问到相同值，在self-join相关的查询中非常必要。“snapshot”在交互式检查统计信息时很有用，但开销较大。默认是“cache”。

如果他在共享内存，如果在重启后沿用

关机前由 checkpoint集成写出到文件系统，并在启动进程启动期间再次加载。像往常一样，如果发生崩溃，统计信息将会被丢弃。

会影响我的监控工具 /脚本吗

所有统计数据监控视图 pg_stat_*继续按原样工作。但请确保为stat_fetch_consistency。如上所述，保留pg_stat_tmp目录不会破坏使用这种方法开发的插件。但是插件开发人员需要针对PG15彻底进行测试。

还有什么

像我这样使用 PG　wait events来了解PG和他的会话在哪里花费了时间。我们在日常生活中使用pg_gather类似的数据采集分析工具。引入了3个新的等待事件：

PgStatsDSA	Waiting for stats dynamic shared memory allocator access
PgStatsHash	Waiting for stats shared memory hash table access
PgStatsData	Waiting for shared memory stats data access