摘要：以前，统计信息收集器通过UDP接收统计信息更新，并通过定期将统计信息数据写出到临时文件来共享统计信息数据。当文件达到数十兆字节时，每秒最多写出两次，这会阻止添加其他有用的统计数据。现在，PostgreSQL 15将做出了重大的改变，开始使用动态共享内存来收集统计信息，而不再使用文件和文件系统。

原文链接：

声明：本文为CSDN翻译，转载请注明来源。

作者 | Jobin Augustine

译者 | 朱珂欣 责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

众所周知，PostgreSQL是一个功能强大的开源对象关系数据库系统，它使用并扩展了SQL语言，并结合了许多可安全存储和扩展最复杂数据工作负载的特性。一直以来，PostgreSQL都在业内拥有极高的声誉，它的每一次版本的发布，都能在国内外获得很大的关注度。

2022年6月30日，PostgreSQL全球开发组宣布PostgreSQL 15的第二个beta版本已可供下载，该版本包含将于2022年末发布的PostgreSQL 15正式版本中的所有特性和功能。

很多人将PostgreSQL 15与PostgreSQL 14相比较，就会发现有一个特别的更新——"统计信息收集器"不见了。曾经是无数开发者的开发瓶颈，如今已经永远消失了。作为PostgreSQL 14和更早版本都需要“统计信息收集器”，它存在怎样的问题呢？PostgreSQL 15又新增了什么样的功能？

被舍弃的统计信息收集器

PostgreSQL的统计信息收集器，是一个支持收集和报告服务器活动信息的子系统。它可以对表和索引的访问计数，以此累计统计信息。并且，还可以跟踪每个表中的总行数、每个表的清理和分析动作的信息，以及统计调用用户定义函数的次数和在每次调用中花费的总时间。但是，PostgreSQL的统计信息收集器同样存在一些问题。

信息传输受到阻力。

由于会话的每个后端是PostgreSQL中的单独进程，因此，收集统计信息并传输并不是容易的事。每个后端将有关它们执行的活动信息发送到单个“统计信息收集器”进程。在过去，这种通信是通过UDP套接字进行，在用户报告的不同类型问题中显示，有三类问题较为明显：统计数据过期；统计数据收集器不运行；自动真空不工作/不启动等。

并且，在过去如果统计数据收集器在特定机器上出现问题，用户其实很难理解出了什么问题。

大量IO出现。

“统计信息收集器”还有一个不利影响——它引起的IO。如果启用DEBUG级别 2，可能会看到不断出现在PostgreSQL 日志中的消息，将导致数据目录所在的装入点上出现大量 IO。

下图是参数值stats_temp_directory所指向的位置。在许多系统上，它将是数据目录中pg_stat_tmp。在Ubuntu/Debian上，它将在/var/run/postgresql中，例如：

PostgreSQL 15中的新动作

面对统计信息收集器带来的弊端，如今，PostgreSQL 15开始使用动态共享内存来收集统计信息，而不再使用文件和文件系统。

正如Andres Freund在文中提及的：

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

现在，统计信息都存储在共享内存中。可以变化的编号对象的统计信息，存储在由动态共享内存支持的 dshash 哈希表中。固定编号的统计信息，存储在普通共享内存中。pgstat.c 的标题包含体系结构的概述。

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

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

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

当然，这些扩展都并非免费的，需要成本。

在新架构中，大多数统计更新时，首先需要在每个进程中本地累积为"pending"（每个后端都有一个后端本地哈希表）。"pending"是指已累积但尚未提交到共享统计系统的待定信息。在提交后或超时后，会被刷入共享内存。由于统计信息是在有人试图读取时被并发更新的，所以读取一致性就成了问题。为了解决读取一致性的问题=PostgreSQL 15引入了一个新的参数：stats_fetch_consistency。它可以取三个值，none、cache 、snapshot：

“none”是最有效的。如果存在期望的监视查询，则无法提供读取一致性。但对于大多数使用来说是可以的。

“cache ”能确保重复访问产生相同的值，对于涉及自联接的查询很重要。

“snapshot”在以交互方式检查统计信息时很有用，但开销更高。

stats_fetch_consistency的默认值为“cache ”。

更新迭代中的疑问与解答

面对PostgreSQL 15新版本中的重大调整，很多用户也会产生相关的疑惑。

统计信息位于共享内存中，如何在重新启动后保存？统计信息在关机前，由检查点进程写出到文件系统，并在启动期间由启动进程再次装回。像往常一样，如果发生崩溃，统计信息将会失效。新功能会影响监控工具/脚本吗？显然是不会，所有的统计监测视图pg_stat_*仍能照常工作，但需要为stats_fetch_consistency选择适当的值。如上所述，保留pg_stat_tmp目录是为了不破坏使用这种方法开发的扩展。但是，扩展开发人员需要针对PostgreSQL 15彻底测试扩展。如何使用PostgreSQL等待事件，了解PostgreSQL及其会话在哪里花费的时间呢？日常生活中使用的数据收集和分析工具，例如pg_gather，利用这些等待事件分析和了解问题。因此，为了更好地监控，PostgreSQL还引入了三个新的等待事件。PgStatsDSA：等待统计动态共享内存分配器访问。PgStatsHash：等待stats共享内存哈希表访问。PgStatsData：等待共享内存统计数据访问。总的来说，PostgreSQL 15不再需要统计信息收集器，而是将统计信息都存储在共享内存中。随着统计收集器及其维护的所有开销的消失，其他子系统，例如自动真空系统，工作量将大大减少，经常查询统计信息的监控工具将会大大降低系统的负载。