实际上经过几个重要特性的跳票之后，我对PG 15的期待最主要集中在FULL PAGE WRITE的优化上了。以前我也多次写文章研究过PG的WAL产生以及CHECKPOINT对高负载应用写入性能的影响。其实这些性能影响大部分来自于FULL PAGE WRITE。因为当某个脏块在CHECKPOINT完成后的第一次被写入的时候，都需要做一次FULL PAGE WRITE，以避免数据库需要恢复时出现块断裂的情况。而FULL PAGE WRITE大规模产生的时候，因为WAL的写入量大大增加，就会导致高并发写应用的性能问题。实际上，当我们在做pg_basebackup等在线备份操作时，也是会引发大量的FULL PAGE WRITE的。缓解这个问题的方法是加大CHECKPOINT的延时，让两次CHECPOINT的间隔更长一些，这样就会大量减少FULL PAGE WRITE。
加大CHEKPOINT的延时也是一个双刃剑，因为这会让数据库在恢复时需要RECOVER更多的页，同时也会在一个CHECKPOINT时集中写入大量的数据块。在瞬时对IO产生更大的影响。
在PG中关闭FULL PAGE WRITE也是一个选项，只不过需要找到支持PG关闭FULL PAGE WRITE的文件系统或者存储系统。我们以前曾经在ZFS上尝试过关闭FULL PAGE WRITE，效果是相当不错的。只不过在我们的大多数PG运行环境中并没有使用ZFS，因此对于PG 15在FULL PAGE WRITE上的优化，我们还是很期待的。
我曾经也考虑过通过WAL压缩来缓解FULL PAGE WRITE的问题，在PG 12上我们做过一个测试，打开WAL压缩。只不过打开WAL压缩后，PG数据块的高并发写入性能并未提升，反而略有下降。能够从以前的PG 12的WAL压缩中获得性能提升的场景十分有限。
PG 15的WAL压缩有了一个十分令人兴奋的改进，除了支持PGLZ外，WAL压缩还支持LZ4和ZSTANDARD两种压缩算法。
从官方的对比来看，ZSTD是一种平衡了压缩解压吞吐量与压缩比的十分优秀的压缩算法，而LZ在压缩比上虽然不如ZSTD，但是在压缩吞吐量上有着特别优秀的表现。这两种压缩算法的引入，必定会大大改善WAL压缩的性能。
因为时间关系，我们目前还没有全面开展PG 15的测试，我想还是等正式版出来后再做完整的测试。不过从目前国外一些朋友对PG 15的测试来看，还是十分令人期待的。我们根据Mark Callaghan的测试用例来看一看效果吧。
和我们的预期相同，使用以前的pglz，对于仅有PK的场景影响并不大，对于PG来说，第一次数据写入，都是创建的新块，不同的算法之间的影响还不算太大。但是对于其他场景影响较大。而使用LZ4的效果极佳，装载性能有了明显的提升。zstd在有多个索引时的数据装载表现出了较好的性能。
不过从上面的测试来看，还是比较简单的，因此这个测试结果页并不说明太多的问题。不过有一点是可以确定的，那就是LZ4和ZSTD的引入，会大大优化WAL 压缩的性能，从而缓解FULL PAGE WRITE的问题，也可以大大减轻DBA优化CHECKPOINT的工作。CHECKPOINT的优化可能会在大多数场景下变得更简单了，我们只要根据自己的场景需求，选择设置WAL压缩参数就可以了。
挺巧的是，在PG 15里，增加了一个新的权限:pg_checkpointer。以往checkpint命令只能由超级用户来执行。而PG 15里，只要是授予这个权限的用户，都可以在自己的应用里执行checkpoint命令了。将checkpoint命令的权限下放，是PG 15细粒度权限控制优化的一部分。不过既然敢下放权限，那就说明checkpoint带来的副作用已经可控了。随着现代硬件的发展，IO问题已经得到了大大地缓解，同时因为WAL压缩的优化，也为checkpoint权限下放提供了有力的支撑。
不过业务场景十分复杂，这个权限还是不要随便授予，因为目前来看，我还没有想清楚，这个权限下放的真实好处在什么地方，什么场景下，应用需要自己去控制checkpoint。如果有一天，DBA发现一个挠头的IO性能问题，是因为某个应用系统频繁执行checkpoint引发的，那就麻烦大了。对于开发人员来说，让每条记录尽快写盘肯定是件喜闻乐见的事情，而对于DBA来说，那可能是个灾难。
