PostgreSQL 怎么用好高版本的PG调优--PG14-PG18

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6 7 8群已经爆满  9群 为纯聊天群，默认不加入不得发广告，自己公众号文章链接等，发一次直接踢，默认加入8群，开10群PolarDB专业学习群115+)

周日上课，同学问PG14 15 16 17 18 在vacuum中的区别是什么随着不同的版本的进化我们PostgreSQL的vacuum有什么变化，今天咱们来总结一篇。

熟悉PostgreSQL的人都知道，PG是传统关系型数据库里面的在完成undo方面的一个奇葩，一个是SQL SERVER 一个是PG，这两个都是不走寻常路。

当然被吐槽是很多使用者的对PG每天的功课，今天我们来总结一下这几个版本在“真空吸尘”中的变化。

1  PG14  PG14 PG15是当前很多企业在用的主力PG的版本，基于企业不会跟着PG一起进行快速疯狂的升级版本，还是以稳定为主，这里PG14 主要的变化是

vacuum_cleanup_index_scale_factor 这个参数被删除了，这个参数是还PG11引入了只到了PG13，因为再PG13上线后，有了新的参数对表中只有insert没有update delete的进行合理的触发autovacuum的机制，autovacuum_vacuum_insert_threshold / autovacuum_vacuum_insert_scale_factor，这两个参数，这两个功能本身是重叠效应的，insert-only 表频繁触发 autovacuum每次 autovacuum 又因 vacuum_cleanup_index_scale_factor 触发全索引扫描，所以在PG14这个参数就被取消掉了。

2 vacuum_defer_cleanup_age  这个参数再PG16被删除了，其中它的功能可以追溯到PG 9 其中主要的目的是为了是为了再流复制的从库中延迟从库被进行vacuum的清理状态，主要是是备库如果进行大量的长时间的查询，如果此时从库进行了VACUUM 的工作，则备库的查询可能因此被迫终止。

而后续因为PG变得越来越只能，PG提供了hot_standby_feedback和Replication Slots两个功能，这两个功能可以让从库反馈自己当前最旧的快照给主库，通过通过replication slots主库可以知道从库的逻辑复制出准确的wal的位置。再后续的PG研发中，这个参数的意义被质疑，其中社区2023年指出，延迟多少个事务并没有意义，延迟事务的初始点可能是瞬间大量的数据写入造成的，从库此时到底延迟多少个事务也是没有意义的，所以这个参数再16版本被删除了。

再PG14 到PG18中除了这两个参数被删除以外还有一些参数变化了值。而这些变化中是伴随着硬件的变化导致的这些值在变化。下面我们挨个进行总结。

vacuum_cost_page_miss  这个参数是在PG14进行变化的，其中主要的原因是vacuum_cost_page_miss 表示"读取一个不在 shared buffers 中的页面"的代价权重。旧默认值 10 意味着：VACUUM 每读一个需要从磁盘换入的页面，就要"记账"10 分。配合 vacuum_cost_limit = 200，VACUUM 每读 20 个冷页面就必须停一次这在机械硬盘时代是合理的——随机 I/O 很贵，需要 throttle。现代服务器普遍使用 SSD/NVMe，随机读延迟从毫秒级降到微秒级。继续用 10 作为"惩罚"会让 VACUUM 进展过慢，死元组堆积，反而引发表膨胀、事务 ID 回卷等更严重的问题。降到 2 后整体的 VACUUM工作变得更加的迅速。

log_checkpoints 再PG15进行了变更，之前默认日志是不记录CHECKPOINT的工作的，而现在随着硬件的更新，CHECKPOINT变得越来越快，而慢的CHECKPOINT 是一个问题，所以从PG15这个值默认就开启了。

log_autovacuum_min_duration 从PG15修改了值从不记录到记录10min的autovacuum，现在的硬件已经很先进，默认应该记录超长时间的autovacuum的操作，这样有助于发现系统运行中的问题，匹配现有先进硬件的工作效率，让运维人员更加注意大表，死元祖过多等问题。

vacuum_buffer_usage_limit 为256kB，而到了PG17更换到了2MB，在 PG 16 之前，VACUUM/ANALYZE 使用 shared buffers 时没有任何"额度"限制。VACUUM 扫描大表时，会大量换入新页面，把 shared buffers 中原本缓存的热数据驱逐出去，导致后续查询命中率暴跌。

vacuum_buffer_usage_limit 引入了一个缓冲区访问策略（Buffer Access Strategy）的 ring buffer 机制：VACUUM/ANALYZE 只能使用指定大小的缓冲区池，超出后采用 ring 方式循环复用，避免"污染"整个 shared buffers。

256kB 过于保守。 换算成页面数只有 32 个 8KB 页，对于现代硬件和大表来说，ring buffer 太小会导致 VACUUM 频繁地"踢出自己刚读进来的页面"，反复重新读取，效率极低。 提升到 2MB（256 个页面）后，VACUUM 能在 ring buffer 中保留更多页面，减少重复 I/O，同时 2MB 对 shared buffers 的整体影响仍然可控。这是社区根据实际 benchmark 和反馈调整后的更合理默认值。

所以使用PG16的用户可以根据PG17对这个参数的变化，来调整这个参数。

effective_io_concurrency 的值从1 变成了16 ，这个改变是从PG18开始的，再PG17最大的问题是异步IO并没有，而PG18增加了异步IO的特性，从PG18开始PG可以从内部进行异步的读取请求，而原来的参数为1相当于不搞预读的机制，也就是完全利用不上异步的IO所以PG18调整成16.

以上是我们第一期的PG这些参数变动的原因分析，希望能帮助你找到版本更新后哪些参数需要进行变动，下次我们继续给家