【PGCCC】PostgreSQL v17 有什么优点？| 翻译
每年秋季，都会有新的 PostgreSQL 版本发布。在查看了PostgreSQL v17 的亮点后，您可能会想，“这有什么大不了的？” 很多人甚至可能对提醒他们应该尽快升级感到不满。是时候解释一下 PostgreSQL v17 有多棒了！
为什么 PostgreSQL v17 中没有引人注目的新功能？
嗯，确实有——我稍后会详细阐述。但肯定没有像“自动分片以实现无摩擦水平扩展”或“内置自动故障转移以实现高可用性”这样引人注目的功能。这并不是因为 PostgreSQL 失去了发展势头：事实上，如今的贡献者比以往任何时候都多。这种看似缺乏创新的情况有几种解释。
PostgreSQL 的功能已经相当完善
几十年来，PostgreSQL 已经发展了很多。回想一下我使用的第一个版本 8.1：autovacuum 仍然是一个新东西，而且有些实验性，复制是使用 Slony 进行的可怕操作，等等。一般的 DBA 从未听说过 PostgreSQL。想想自那以后出现的所有新功能，真是令人惊叹。没有它们我们怎么生活？
多年来，许多聪明人做出了许多伟大的贡献。大多数简单、明显的改进（以及一些困难的改进！）都已经完成。剩余的缺失功能才是真正困难的。
为 PostgreSQL 做贡献变得越来越困难
多年来，随着贡献者的数量和 PostgreSQL 在世界范围内的重要性不断增长，对新贡献者的需求也随之增长。如今，每个代码贡献都必须经过同行评审过程。越来越多的补丁争夺评审者和提交者的兴趣。花时间改进和合并别人的工作远不如开发自己的酷炫功能有吸引力。这个狭窄的瓶颈意味着，如果你想让你的贡献得到认可，你需要大量的时间和决心。
不幸的结果是，贡献者会灰心丧气，很多有趣的贡献都无法完成。总会有人在你的补丁中发现瑕疵，人们很快就会列出一份理想的附加功能清单。即使有人提交了你的补丁，也不能保证它会保留下来：在 PostgreSQL v17 的开发周期中，许多功能被撤销了，因为人们发现它们存在一些不容易修复的问题。我的同事 Ants 简洁地评论道：“PostgreSQL 开发发生在五次提交和一次撤销中。” PostgreSQL 社区意识到他们应该改进开发过程。只是对于如何做到这一点没有达成共识。
但我相信贡献者面临的问题也有一些积极的方面。开发过程可能令人沮丧，但所承诺的功能通常是稳定和成熟的。PostgreSQL 也不太可能陷入“渐进式功能主义”：成功的旧软件增加了如此多的功能（缺陷？），最终一个新的、精简的软件占据了主导地位并将其抛在身后。在某种程度上，PostgreSQL 十年的成功故事和其稳定性和健壮性的声誉归功于其缓慢的开发过程。
PostgreSQL v17 中的出色新功能
但是让我们来看看 PostgreSQL 的新进展。我不会一一列出它们（你可以在发行说明中找到它们），但我会尽力激起你对 PostgreSQL v17 的兴趣。
PostgreSQL v17 中不显眼的性能改进
每个 PostgreSQL 版本都伴随着性能改进。通常，这些改进都是针对优化器的。在许多细微方面，优化器在各个版本中都变得越来越智能。人们经常问我，“如果升级，我的应用程序会变得更快吗？”大多数时候，我无法指出他们的工作负载将受益的具体方式。但是，如果您（例如）从 v13 升级到 v17，这些改进的综合效果就足以让我有把握地预测，升级后大多数数据库工作负载将运行得更快。
随机挑选其中的一项精华，从 v17 开始，PostgreSQL 将在带有和 的查询中考虑快速启动计划，UNION ALLLIMIT这不是很好吗？另一个精华是PostgreSQL 将使用 b 树索引扫描更有效地处理IN-lists 。
入围的 v17 性能功能是对 的改进VACUUM。在 v17 中，VACUUM可以一次性处理更多行。它还将更有效地冻结旧行，从而减少写入的 WAL 量。这是许多性能改进的典型特征：您不会在任何单个 SQL 语句上看到明显的影响，但自动清理将消耗更少的资源并减少机器上的负载。
PostgreSQL v17 中的新内置排序规则提供程序
PostgreSQL v17 有一个新的内置排序规则提供程序。这是一个发展的开始，也许有一天会摆脱PostgreSQL 中最烦人的问题之一：PostgreSQL 对外部排序规则提供程序（如 C 库或 ICU 库）的依赖。这种依赖要求您在需要时重建字符串索引
数据库使用自然语言排序规则，
你升级了提供排序规则的库
到目前为止，内置排序规则提供程序仅支持二进制排序规则。这对于 PostgreSQL 中的新功能来说很典型：一年通常太短，无法编写完整的功能，因此第一个版本仅提供部分实现。后续版本可以添加更多功能。我希望有人会添加自然语言排序规则，并且这些排序规则在主要版本中保持稳定。这将消除升级后重建索引的需要。目前，黑客列表中正在讨论新排序规则应该有多稳定；如果您有意见，请发表意见。
PostgreSQL v17 中的逻辑解码可以在发布者发生故障转移后继续运行
到目前为止，使用高可用性故障转移群集作为源时很难使用逻辑复制。当发布者死亡并且流复制备用服务器接管时，您通常必须从头开始重建逻辑复制。现在，如果您
- failover = true使用和定义您的订阅
- 你把流复制的复制槽放入新的参数中synchronized_standby_slots
逻辑解码将等待，直到流复制备用服务器收到 WAL。这样，逻辑解码可以在故障转移后继续。
如果您在 v17 之前需要这样的设置，则可以求助于第三方扩展pg_failover_slots，但在 PostgreSQL 中内置此功能是一大进步。
EXPLAINPostgreSQL v17 中的改进支持
如果您像我一样需要调优查询，您就会知道这EXPLAIN是分析查询性能不可或缺的工具。v17EXPLAIN中有一个值得注意的新选项：SERIALIZE添加有关执行器将语句输出转换为输出格式所花费时间的统计信息。如果没有这个，您就无法看到反编译大列并将结果转换为字符串所需的时间。
PostgreSQL v17 中支持增量备份
PostgreSQL v17 的任何功能列表都不能忽略这一重要改进。备份大型数据库可能需要很长时间。如果您负担不起每日备份pg_basebackup，那么在 v17 之前您的选择有限：
- 你可以减少基础备份的执行频率，并接受更长的恢复时间
- 您可以使用低级备份 API和存储快照技术
- 您可以使用第三方产品pgBackRest，它支持增量备份
从 v17 开始，您还可以使用 执行增量备份pg_basebackup。为此，您必须打开新的WAL 摘要功能，该功能可提取自上次基础备份以来哪些块已更改的信息。要恢复增量备份，您必须使用pg_combinebackup将其合并到上一个基础备份中。
原文链接
#PG证书#PG考试#postgresql初级#postgresql中级#postgresql高级
原文地址：https://blog.csdn.net/PGCCC/article/details/142813941
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！