PostgreSQL 15 中值得关注的“大更新”( 二 )

2025-12-25 PostgreSQL

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

PostgreSQL 15 中值得关注的“大更新”

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

“none”是最有效的。如果存在期望的监视查询，则无法提供读取一致性。但对于大多数使用来说是可以的。
“cache ”能确保重复访问产生相同的值，对于涉及自联接的查询很重要。
“snapshot”在以交互方式检查统计信息时很有用，但开销更高。

【PostgreSQL 15 中值得关注的“大更新”】
stats_fetch_consistency的默认值为“cache ” 。
更新迭代中的疑问与解答
面对PostgreSQL 15新版本中的重大调整，很多用户也会产生相关的疑惑。

统计信息位于共享内存中，如何在重新启动后保存？

统计信息在关机前，由检查点进程写出到文件系统，并在启动期间由启动进程再次装回。像往常一样，如果发生崩溃，统计信息将会失效。

新功能会影响监控工具/脚本吗？

显然是不会，所有的统计监测视图pg_stat_*仍能照常工作，但需要为stats_fetch_consistency选择适当的值。如上所述，保留pg_stat_tmp目录是为了不破坏使用这种方法开发的扩展。但是，扩展开发人员需要针对PostgreSQL 15彻底测试扩展。

如何使用PostgreSQL等待事件，了解PostgreSQL及其会话在哪里花费的时间呢？

日常生活中使用的数据收集和分析工具，例如pg_gather，利用这些等待事件分析和了解问题。因此，为了更好地监控，PostgreSQL还引入了三个新的等待事件。

PgSta tsDSA：等待统计动态共享内存分配器访问。
PgStatsHash：等待stats共享内存哈希表访问。
PgStatsData：等待共享内存统计数据访问。

总的来说，PostgreSQL 15不再需要统计信息收集器，而是将统计信息都存储在共享内存中。随着统计收集器及其维护的所有开销的消失，其他子系统，例如自动真空系统，工作量将大大减少，经常查询统计信息的监控工具将会大大降低系统的负载。

推荐阅读

上一篇：ViewBinding 与 Kotlin 委托双剑合璧

下一篇：如何利用 xUnit 框架对测试用例进行维护？