PostgreSQL 13 正式发布

来源: OSCHINA
编辑:
2020-09-25 07:34:00

PostgreSQL 13 已正式发布,新版本对索引和查找系统进行了重大改进,大型数据库因此受益甚多,包括节省了空间并提高了索引的性能,使用聚合或分区的查询的响应时间更快,使用增强的统计信息时更好的查询计划(query planning)等。

除了并行化清理(parallelized vacuuming)和增量排序(incremental sorting)等呼声较高的功能外,PostgreSQL 13 还为大大小小的工作负载提供了更好的数据管理体验,并对日常管理进行了优化,为应用开发者提供了更多便利,并增强了安全性。

性能提升

在先前 PostgreSQL 版本的基础上,PostgreSQL 13 可以有效地处理 B 树索引(PostgreSQL 的标准索引)中的重复数据,从而降低 B 树索引所需的整体空间使用率,同时提高了整体查询性能。

PostgreSQL 13 引入了增量排序,即在查询中较早步骤的排序数据可以加速后面步骤的排序。此外,PostgreSQL 现在可以使用扩展的统计信息(可通过CREATE STATISTICS访问)来为带有OR子句和INANY查找列表的查询创建改进的计划。

在 PostgreSQL 13 中,更多类型的聚合查询和分组查询可以利用 PostgreSQL 的高效哈希聚合功能,因为具有大型聚合的查询不必完全放入内存。对分区表的查询也得到了性能提升,因为现在有更多的情况下可以修剪分区和直接联接分区。

优化管理

清理(Vacuuming)是 PostgreSQL 管理的一个重要部分,使数据库在更新和删除行后能够回收存储空间。此过程也会带来管理上的挑战,尽管之前的 PostgreSQL 版本已经做了一些工作来减轻清理的开销。

PostgreSQL 13 通过引入用于索引的并行化清理来继续改进清理系统 。具体来说,VACUUM 命令能够并行处理索引。可以使用 VACUUM 命令上的新 PARALLEL 选项(或 vacuumdb 上的 --parallel)来访问其功能,该选项允许用户指定用于清理索引的并行 Worker 进程的数量。要注意的是,这不适用于 FULL 选项。由于管理员可以选择要运行的并行 Worker 进程的数量,因此可以针对特定的工作负载调整此新功能的使用。除了这些性能优势之外,数据插入现在还可以触发自动清理过程。

复制插槽(Replication slots),用于防止在复制副本接收到预写日志(WAL, write-ahead logs)之前将其删除,现在可在 PostgreSQL 13 中进行调整,以指定要保留的 WAL 文件的最大数量, 有助于避免磁盘空间不足错误。

PostgreSQL 13 还增加了更多让管理员可以监控数据库活动的方法,包括从 EXPLAIN 中查看 WAL 使用情况的统计信息、流式基础备份的进度,以及 ANALYZE 命令的进度。此外,可以使用新的 pg_verifybackup 命令验证 pg_basebackup 命令输出的完整性。

应用开发

PostgreSQL 13 对来自不同数据源的 PostgreSQL 数据类型进行了优化。此版本在其 SQL/JSON 路径支持中增加了datetime()函数,它可以将有效的时间格式(如 ISO 8601 字符串)转换为 PostgreSQL 原生类型。此外,UUID v4 生成函数 gen_random_uuid() 现在无需安装任何扩展即可使用。

PostgreSQL 分区系统更加灵活,因为分区表完全支持逻辑复制和 BEFORE 行级触发器。

PostgreSQL 13 中的FETCH FIRST语法现已扩展为可包含WITH TIES子句。 指定时,WITH TIES包括基于ORDER BY子句的结果集中最后一行相匹配的任何其他行。

安全性增强

在之前的版本中,新扩展只能由数据库超级用户安装。为了更容易利用 PostgreSQL 的扩展性,PostgreSQL 13 增加了“可信扩展”的概念——允许数据库用户安装超级用户标记为“可信”的扩展。某些内置扩展默认被标记为“可信”,包括pgcryptotablefunchstore等。

对于需要安全认证方法的应用,PostgreSQL 13 允许客户端在使用 SCRAM 身份认证时要求通道绑定,并且 PostgreSQL 外部数据包装器(postgres_fdw)现在可以使用基于证书的认证。

详情查看发布公告

下载地址:https://www.postgresql.org/download/

展开阅读全文
点击加入讨论🔥(39) 发布并加入讨论🔥
本篇精彩评论
语法:PostgreSQL 号称世界上最先进的数据库多年,SQL标准中的功能算是各大数据库中支持最全的。与MySQL相比,高级点的功能在PG中SQL就能搞定,而使用MySQL你得取出数来,在开发端写算法搞定。
性能上,百万行数据插入,PG耗时比MySQL少,之前对比一次过为三分之一。在具体开发上,由于PG支持功能丰富,一些需求可以一个SQL搞定,因此性能上一般比使用MySQL时使用代码自己处理效率高点,当然具体情况要具体分析。
!!!!但是,但是!!!!
MySQL比PG流行,在国内MySQL用得要比PG多得多,有得程序员甚至还没有听说过PG。
现在MySQL在国内的教程,文档(经验,填坑历史,人才),在业界得工具,产品,开发(框架,云等)等周边支持上都比PG丰富得多,总得下来,给我得感觉,MySQL使用起来显得“简单,容易,事少,如果单单只是做OLTP开发,MySQL就显得优势明显了。
2020-09-27 10:07
12
举报
生产环境已升级到 PostgreSQL 13 希望 PG 越来越好
2020-09-25 08:33
12
举报
pg最先进也是最傻的数据库了,类型转换要命的难受,联合查询Null也会和时间类型不匹配,日期类型不能用''作为空值,日期类型也不能不传''单引号,不传会提示int不能用于日期。糟糕透顶,满世界都是::类型转换,视图还给你格式化一下,if类似的判断还莫名其妙的给你加上类型转换。定义函数返回值,虽然有泛型可是傻傻的报错。定义的函数大多只能传入字段,不能传入值,否则也报错。查询性能尚可,比sqlserver2019慢一半的样子,而mysql8又比pg13慢一半的样子,指的是包含不少子查询的情况下。pg13这个类型处理不改,真的很劝退。只能用太傻来形容了,好歹按字段类型自己转换一下,为什么就直接报错了。
2020-09-30 12:47
8
举报
一个SQL搞定,通常并不是什么好的方案
2020-09-30 10:52
4
举报
Great! 甩开MySQL一百条街。
2020-09-25 08:17
4
举报
39 评论
11 收藏
分享
返回顶部
顶部