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倍的性能提升还是挺令人满意的。

上面这句话包含了两方面的内容，一方面是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性能指标久矣。

在PG16中，这些问题得到了改善，pg_stat_io可以按照backend类型对IO进行统计，包括读写次数、读写时间、回写次数等信息。

失望于没有看到XID64的朋友，PG16给了大家一个安慰奖：

可能是有点不好意思吧，在新特性中仅仅提了上面一句话。

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社区的大佬们还是偏于保守，不过对于数据库产品来说，稳定是第一位的，确保数据安全的优先级是远高于创新的，所以大家也不要太失望。