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倍的性能提升还是挺令人满意的。
上面这句话包含了两方面的内容,一方面是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社区的大佬们还是偏于保守,不过对于数据库产品来说,稳定是第一位的,确保数据安全的优先级是远高于创新的,所以大家也不要太失望。
本文分享自微信公众号 - 开源软件联盟PostgreSQL分会(kaiyuanlianmeng)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。