首先

喵~。
就像平常一样，现在是进行 PostgreSQL 新版本差异预调研的时期了。
所以，这次我们来研究一下 PostgreSQL 14 和 PostgreSQL 15 的配置参数的差异。

调查方法的描述

• PostgreSQL 14/PostgreSQL 15 beta1を使って、以下の操作を実行。

initdb（-Dオプションと-U postgresオプションのみ指定）を実行。
生成されたデータベースクラスタを起動。
postgresユーザでpostgresデータベースにログイン。
psqlの\aメタコマンドを実行。
psqlの\oオプションで出力ファイルを指定。

SELECT name, setting, unit, category, context, vartype, min_val, max_val, enumvals FROM pg_settings ORDER BY name;を実行。1

生成されたPostgreSQL 14の結果とPostgreSQL 15-beta1の結果をdiffる。

调查结果 chá jié guǒ)

请提供更多上下文。”行数”在这里是一个很抽象的词汇，它可以有不同的意思，因此需要了解具体的背景以便用中文准确地进行表达。

选择语句中的行数

分析器

以下是PostgreSQL 14.3和PostgreSQL 15 beta1之间配置参数的差异摘要。
还有相当多的新增参数。

新增的参数 de

PostgreSQL 15中引入了许多新参数。

允许就地表空间

类别是“开发者选项”。
控制是否允许将表空间创建为pg_tblspc目录的参数。
默认值为关闭。
从参数的说明中可以看出，这个参数在配置主服务器和备份服务器位于同一台服务器上并进行测试的场景中使用。
在正常运营中，我认为不会设计在同一台服务器上配置主服务器和备份服务器的HA架构，所以可能不会用到。

当手头只有一台设备进行关于复制的小测试的时候，我想要回忆起来的应该是什么参数呢？

归档图书馆

类别是“预写式日志”。
它似乎是用于指定归档库，以替代archive_command。
默认值是空字符串。
如果设置为空字符串，则仍然使用archive_command来进行归档。

启用分组重排序

这个类别是“查询计划”。
一个参数用于启用或禁用GROUP BY子句的键排序。
默认值为启用状态。

这个参数与发布说明书中的以下项目相关。

允许通过GROUP BY对列顺序进行排序以优化（Dmitry Dolgov、Teodor Sigaev、Tomas Vondra）。
可以使用服务器变量enable_group_by_reordering来禁用此优化。

必须运行包含GROUP BY排序的查询才能确认其效果，否则无法知晓。

记录启动进程间隔

所述类别为“错误报告和日志记录”。
在PostgreSQL的启动过程中，好像可以记录长时间的处理过程。
默认值为10000毫秒（10秒），通过将其设置为-1可以禁用此日志记录。
根据参数说明，这是一个设置间隔的参数，例如，如果设置为10000，则在启动过程中某些操作耗时25秒时，将会记录两次。

在实际运行中，启动过程需要花费10秒钟这样的情况大概有多少呢…？
并非主体功能，而是与PostgreSQL主体一起启动的扩展功能的工作进程如果出现故障，这种情况可能会有用吗？

预取式恢复

该分类的是”写前日志”。
在使用WAL进行恢复时，应该控制是否尝试预取尚未在缓冲池中的块，这些块在WAL段文件内被引用。
该属性的类型是枚举。
取值范围为on，off，try（默认值）。

似乎 “try” 是指仅当操作系统提供了 posix_fadvise 函数时才启用预取。如果在不支持 posix_fadvise 函数的环境中开启该选项，会导致错误吗？

递归工作表因子 (Dìgǔ Gongzuo Yinzi)

这个类别是”查询计划”。
参数前面的说明。

把规划器对递归查询工作表平均大小的估计设置为查询初始非递归项估计大小的倍数。

我读了这句话，但还是有点不太明白。这句话的意思是将递归查询的工作表的平均大小设置为查询的首个非递归项的估计大小的倍数，并作为规划者的估计值。

在执行递归查询，如图形数据的最短路径搜索时，是否可以进行调整以提高效果呢？最近我稍微研究过类似 Apache AGE 的扩展功能，使用它时是否会有好处呢？

共享内存大小

此类别称为“预设选项”。基本上，这些参数是无法调整的。
读到说明“报告主共享内存区域的大小，并将其取最接近的兆字节上取整。”但实际上不太明白它到底在说什么。

然后，默认值是一个神秘的数字143。这个数字是什么呢…?

所以，就这个参数来说，目前还不太清楚实际意义…。

巨页面中的共享内存大小

该类别被标记为“预设选项”。基本上，这些参数是无法进行调整的。

阅读说明后可知，“根据指定的 huge_page_size，报告在主共享内存区域所需的huge页面数。如果不支持huge页面，则该值为-1。”在我们这次调查的环境下（Amazon Linux2），默认值为72。这个值可能是在进行配置时确定的哦……

统计数据提取的一致性

类别为”运行时统计”。
决定在事务内多次访问累积统计值的行为。
类型为枚举。
取值范围如下。

嗯，cache和snapshot的区别是缓存范围的不同吧。
感觉验证这个参数有点麻烦…。

解码缓冲区大小

类别是“写前日志”。
服务器能够在WAL中向前查找多远以寻找预取的块的限制值。该参数与PostgreSQL 15中新增的recovery_prefetch参数相关。
如果该值没有单位指定，则将其视为字节。
默认值为512kB（=524288）。

修改过的参数

计算查询编号

在値域中新增了回归(regress)。
计算查询标识的値域如下所示。

实际上，这个数值范围的添加也被最近的次要版本升级（例如：PostgreSQL 14.3）进行了向前兼容。2
（因此，在比较 PostgreSQL 14.3 和 PostgreSQL 15beta1 时无法检测到……）

哈希内存乘数

默认值从1.0更改为2.0。

用于计算可用于散列基础操作的最大内存量。它是将 hash_mem_multiplier 乘以 work_mem 的结果。PostgreSQL 15 的默认值为 2.0，这意味着散列运算通常会使用普通 work_mem 的两倍内存。

这个参数是从PostgreSQL 13开始添加的，但实际上我从来没有正确地进行调整过…

日志目标

在值域中添加了jsonlog。
jsonlog按名称将服务器日志以JSON格式输出。
为了以JSON格式输出，需要将logging_collector设置为on。
JSON格式文件的输出位置默认为log/postgresql.json。
JSON格式的服务器日志将呈现如下所示。

{"timestamp":"2022-05-22 09:15:50.883 JST","pid":21357,"session_id":"628980b6.536d","line_num":5,"session_start":"2022-05-22
09:15:50 JST","txid":0,"error_severity":"LOG","message":"database system is ready to accept connections","backend_type":"post
master","query_id":0}
{"timestamp":"2022-05-22 09:17:24.220 JST","user":"postgres","dbname":"postgres","pid":21376,"remote_host":"[local]","session
_id":"628980e6.5380","line_num":1,"ps":"SELECT","session_start":"2022-05-22 09:16:38 JST","vxid":"3/6","txid":0,"error_severi
ty":"ERROR","state_code":"42703","message":"column \"hoge\" does not exist","statement":"SELECT hoge;","cursor_position":8,"a
pplication_name":"psql","backend_type":"client backend","query_id":0}

用人类视角来看，该文本的可读性并不好，但如果使用程序来处理服务器日志，则可能会更轻松。关于jsonlog的输出格式，将在另一篇说明文章中补充解释。

自动清理最小持续时间

默认值从-1更改为60000毫秒。
-1用于禁用日志记录，当自动清洁需要很长时间时，但现在默认值已更改为超过60秒时会记录日志。

检查点记录

默认值从关闭变为开启。
当出现性能问题时，可能需要查看服务器日志来确认是否与检查点有关，但有时即使进行了分析，也无法查看到与检查点相关的日志，因此有可能无法得知情况。通过将默认值设为开启，可能可以避免这种令人遗憾的情况发生。

赛道_*

没有更改默认值等。
只有变量的类别(category)发生了变化。

目标变量有以下六个。

• track_activities

• track_activity_query_size

• track_counts

• track_functions

• track_io_timing

track_wal_io_timing

华尔街数据压缩

布尔类型已经被更改为枚举类型。
此外，值的范围也已被更改如下。

该参数控制是否压缩在full_page_writes为on时，或在基本备份期间写入WAL的完整页图像。这类参数似乎是TOAST压缩方法的延伸，该方法从PostgreSQL 14开始引入（现在支持pglz和lz4），并扩展到WAL的完整页图像。

被删除的参数

统计临时目录

尽管没有详细列出原因，但似乎在PostgreSQL 15中被移除。

移除不必要的服务器变量stats_temp_directory（Andres Freund，Kyotaro Horiguchi）。

這個參數是用來設置臨時統計資料存儲目錄的，默認值是pg_stat_tmp（相對於數據庫集群的路徑）。這個參數之所以可調整是因為。。。

通过指定基于RAM的文件系统，可以减少物理I/O需求，并有可能提高性能。

有这样的一个故事，关于在 PostgreSQL 15 的开发过程中，是否被删除了，毕竟没有太大的效果……（我没有一直追踪 hacker-ml 的进展）。

最后

根据目前来看，PostgreSQL 15 的许多设置参数似乎发生了变化。
由于本文只是一个桌面研究，所以以后我想实际操作每个功能，确认增加了哪些新功能。
此外，这个调查结果仅仅是 beta1 版本的结果，因此在之后的 beta2 版本及以后可能会有变化。我打算在 beta2 版本及以后的发布中重新确认。