PG 16的第一个预览版发布了，也就是说PG社区已经锁定了PG 16的基本功能，到正式版发布虽然还有一段时间，不过在正式版里，剪掉某些功能是有可能的，增加某些功能基本上是无望了。很多PGer对于PG 16的功能更新有些失望，这次的失望恐怕要高于PG15。PGer最大的失望莫过于XID 64、内置连接池等重要功能的缺席。我也看到了网上一些朋友对PG16挤牙膏似的功能更新感到无力吐槽。事实是否如此呢？今天老白以自己的观点来给大家解析一下PG16更新的Highlight。
16个“亮眼”的新功能Highlight的第一个就是性能方面的，首先是并行查询方面的性能提升。实际上如果仔细研究一下这些文字，里面包含的信息还是挺丰富的。在并行执行方面，PG这些年还是下了很大功夫的，在近期的每个版本中都会出现一些和并行执行相关的新特性。这说明PG核心研发团队对于硬件技术的提升还是跟随得很紧的，希望利用现代硬件的新特性来为PG的性能做加持。
PostgreSQL 16增加了更多的并行查询能力，比如允许FULL和RIGHT JION在并行模式下执行，这两类都是SQL中常有的操作，可以对十分广泛的SQL执行加速。允许parallel group和parallel aggregate则会对统计类的SQL加速，从而更快的执行一些大数据量分析的SQL。
另外一个性能方面的提升中的“增量排序”是指在排序时，可以先对一部分数据进行排序，然后逐步加入更多的数据，而不是一次性对所有数据进行排序，从而节省内存和时间。PostgreSQL 16可以在SELECT DISTINCT 查询中使用增量排序，从而提高查询的性能。
“窗口查询”是指在执行一个select查询时，可以对结果集中的每一行或每一组行应用一些聚合函数或分析函数，比如求和、平均、排名等。PostgreSQL 16对窗口查询进行了一些优化，比如支持使用frame clause来指定窗口范围，支持在此类SQL中，对RANGE和LIST分区使用push down predicate来过滤不需要的数据，支持使用partition pruning来跳过不相关的分区等，并且支持在右外连接条件中使用“anti join”。
PG 16的并行执行并不仅仅限于SELECT，对于BULK LOADING操作也支持并发模式，这个改进可以将COPY命令的性能提升3倍。大数据量装载在数据库迁移和ETL等操作中都十分常见，3倍的性能提升还是挺令人满意的。
This release also introduces support for CPU acceleration using SIMD for both x86 and ARM architectures, including optimizations for processing ASCII and JSON strings, and array and subtransaction searches. Additionally, PostgreSQL 16 introduces load balancing to libpq, the client lib。
上面这句话包含了两方面的内容，一方面是PG16对SIMD的支持，一方面是libpq支持LOAD BALANCE了。不知道为什么要把这两件事放在一段里，目前还没有测试过，所以也不清楚二者是否有关。不过这意味着libpq可以自动选择最佳的服务器来处理客户端的请求，从而提高性能和可靠性。另外这个功能也意味着今后PG数据库的高可用与读写分离将会有更加简单的实现，这也为某些以读为主的应用提供了一种更加简单的实现方式。
上面那句话的另外一面是关于SIMD的，PG 16支持SIMD了。这是一件大事吗？对PG来说也许是的，不过SIMD已经不是啥新鲜玩意了，如果早上几年，这也许算是一个创新。Oracle 12c的IMDB就已经开始使用SIMD来做行列转换了,Clickhouse等数据库也早就用上了，国产数据库也大量使用SIMD，比如openGauss前些年就在宣传对SIMD的支持了。SIMD 是一种 CPU 的加速技术，可以充分利用CPU指令集的特性，比如INTEL的AVX-512指令集的能力实现超宽向量操作，让 CPU 一次处理多个数据，从而提高运算速度。PostgreSQL 16针对X86和ARM CPU 支持使用 SIMD 技术来加速一些常见的操作，比如处理 ASCII 和 JSON 字符串。
针对这个特性，放在2023年的今天还放在HIGHLIGHT里作为一个亮点来介绍，似乎有点大惊小怪了，好像当年Oracle 12c的新特性里压根就放不下这一条。倒是一些国产数据库只要用上一点SIMD就号称在数据库中支持矢量计算了。
在逻辑复制上，PG16也发布了一些新特性，其中最重要的是可以将逻辑复制的解码工作从主库下载到从库，这可以大大减轻主库的工作压力，在高负载情况下提高主库的性能。另外在对大事务的复制优化上，PG16支持对大事务进行并行APPLY，从而解决大事务导致逻辑复制延时过大的问题。另外一个性能优化是，在逻辑复制UPDATE/DELETE操作时，不仅仅可以使用主键，也可以使用其他索引。上述关于逻辑复制的性能优化，算是中规中矩，从库解码和大事务并行APPLY都是十分有价值的更新。
今天时间有限，关于开发体验和安全的新特性我们先跳过，我们直接来看下一条：监控与管理。这是DBA最为关心的内容。其中最令DBA兴奋的是pg_stat_io。DBA苦无法获知PG的IO性能指标久矣。在D-SMART里，PG数据库的健康模型中冠以PGIO的指标十分稀缺。
可以看到，在D-SMART的健康模型中，关于PG IO方面的指标只有区区数个，而且还都是参考性不够强的指标。
在同门兄弟openGauss中，指标的数量与质量都有了明显的提高，我们的健康模型也更能够反映出数据库的IO负载与性能状态。在PG16中，这些问题得到了改善，pg_stat_io可以按照backend类型对IO进行统计，包括读写次数，读写时间，回写次数等信息。
对于失望于没有看到XID64的朋友，PG16给了大家一个安慰奖：“This release includes improvements to the page freezing strategy, which helps the performance of vacuuming and other maintenance operations.”。可能是有点不好意思吧，在新特性中仅仅提了上面一句话。PostgreSQL 16通过使用主动的时间线来驱动 VACUUM 冻结，从而避免不必要的冻结元组。这样可以减少自动清理的频率，并提高清理效率。
关于这个问题，大家意见比较大是可以理解的，不过我们也要理解修改XID的难处。以Oracle为例，在2002年左右爆发的SCN HEADROOM问题一些老DBA可能还记得，这是因为48位的SCN以及40年前的设计者为了让Oracle数据库能保用500年而设计的每秒SCN增长16K的天花板。哪怕是刚刚出现问题的2002年，每秒新增1.6万事务的估计显得有点科幻，不过随着硬件能力的提升，现在一秒钟干20万笔事务的数据库系统已经很常见了。二十年前问题刚刚爆发时，Oracle官方就认为彻底解决该问题的方法是将48位的SCN升级为64位。不过20年过去了，Oracle还没有实现这个升级，而是把数据库SCN必须你能够保用500年这一条改掉了，谁家的数据库能一库到底500年？让SCN HEADROOM突破16K的限制比把SCN改成64位简单多了。我想目前PG社区的老大们目前也在往这方面想吧。
今天因为时间问题，我就写这么多吧，一些其他的特性就不做详细的解读了。目前我也仅仅是解读了文档，并没有真正的去使用PG16，有些东西是不是我想象的这样，这就需要今后实践中去体验了。从对PG16新特性的解析上看，虽然说对于一个年度更新大版本的数据库产品来说，这些提升还是说得过去的，不过也看出了PG社区的大佬们还是偏于保守，不过对于数据库产品来说，稳定是第一位的，确保数据安全的优先级是远高于创新的，所以大家也不要太失望。
