试用即将发行的PostgreSQL 15的人会发现少了一个后台进程：​

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

来和PostgreSQL 14比较一下：​

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的工作内容是什么？

新手用户可能想知道它是什么以及为什么PG 14和更早版本需要它。至少会有一些用户对用于查询计划的表级统计信息的收集(ANALYZE)感到困惑。但这是不同的。PostgreSQL跟踪每个进程的所有活动以获得累积统计信息，例如扫描表或索引的次数，或者最后一次vacuum或autovacuum在表上运行的时间，或者autovacuum在表上运行的次数等。所有stats collector收集的数据可通过不同的pg_stat_*视图获得。

问题点

由于会话的每个后端都是PostgreSQL中的一个单独进程，因此收集统计信息并传输并不是一件容易的事。每个后端将有关他们所做的活动的信息发送到单个"stats collector"进程。

这种通信过去是通过UDP套接字进行的。这种方法有很多问题，这不是一个可扩展的模型。

用户经常报告不同类型的问题，例如:过时的统计信息、stats collector未运行、autovacuum无法工作/启动等。

如果stats collector在特定机器上出现问题，过去真的很难理解出了什么问题。

"stats collector"的另一个不利影响是它引起的IO。如果启用DEBUG级别2，可能会看到不断出现在PostgreSQL日志中的消息，例如：​

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)

PostgreSQL 15中的新特性

开始使用动态共享内存来收集统计信息，而不再使用文件和文件系统。

以前，统计收集器通过UDP接收统计更新，并通过定期将统计数据写入临时文件来共享统计数据。这些文件可以达到数十兆字节，并且每秒最多写入两次。这会阻止我们添加其他有用的统计数据。

现在统计信息存储在共享内存中。可变编号对象的统计信息存储在dshash哈希表中（由动态共享内存支持）。固定编号的统计信息存储在普通共享内存中。

pgstat.c的头文件包含该架构的概述。

不再需要统计信息收集器，将其删除。

现在副本删除了已删除对象的统计条目，从完全关闭的副本启动时不再需要重置统计信息。

显然，参数stats_temp_directory不见了。因此，我们不需要pg_stat_tmp目录，该目录是在数据目录（或其他位置）中，在该目录生成和读取所有统计文件。然而，仍保留此目录是因为不会破坏许多依赖于该目录的扩展，例如pg_stat_statements。

在加载扩展库之前，目录保持为空。例如，如果我们加载pg_stat_statements库，目录中会出现一个文件。​

$ ls pg_stat_tmp/
pgss_query_texts.stat

当然，扩展不是免费的，他们也有对应的成本。

在新架构中，大多数统计更新首先在每个进程中本地累积为"pending"（每个backend都有一个backend本地哈希表）。"pending"是指它们已累积但尚未提交到共享统计系统(shared stats system)。之后会在提交或超时后刷新到共享内存。

由于统计数据会在有人尝试读取时同时被更新，因此读取一致性就出现了。因此PostgreSQL 15引入了一个新参数：stats_fetch_consistency，它可以取三个值none、cache 或snapshot​：

·"none"是最有效的。但是，将不会提供读取一致性。但对于大多数使用来说应该没问题。

·"cache"确保重复访问产生相同的值，这对于涉及例如自连接(self-joins)是有必要的.

·"snapshot"在交互式检查统计信息时很有用，但开销更大。

默认为"cache"

如果是在共享内存中，重启后如何保持呢？

在被shutdown之前，检查点进程会将这些统计信息写入文件系统，重启后可以再次被加载。通常，如果是crash了，统计信息就丢失了。

这一改动是否会影响我的监控/脚本？

监控视图pg_stat_*会继续起作用。但是，要确保取得是stats_fetch_consistency的恰当的值。如上所述，pg_stat_tmp目录只是为扩展保留的。

其它

很多人像我一样，使用postgresql的等待事件来理解postgresql以及会话都把时间花费在哪的人。数据收集和分析工具，比如pg_gather，通过使用等待事件来分析问题。

​为了更好地监控postgresql，三个新的等待事件被引入了：

·PgStatsDSA：等待统计动态共享内存分配器访问

·PgStatsHash：等待stats共享内存哈希表访问

·PgStatsData：等待共享内存统计数据访问

随着统计收集器的所有开销及其维护的消失，其他子系统（如 autovacuum）要做的工作就更少了。

此外，经常查询统计信息的监控工具预计会大大减少系统负载。