只需升级：PostgreSQL12怎样提升性能

只需升级：PostgreSQL12怎样提升性能

翻译自：PostgreSQL Performance

世界上最先进的开源关系型数据库的最新版本PostgreSQL 12即将在最近的几周内发布，除非出现任何挫折。在此之前，该项目每年提供一次新的数据库功能，坦率地说，这非常令人惊讶，这也是我想加入PostgreSQL社区的原因之一。

在我看来，这与往年有所不同，PostgreSQL 12不包含一个或两个每个人能指出并说“这是 ‘FEATURE’ release”的单个特征（分区和并行查询是最近能想起的例子）。我曾经半开玩笑的认为这一版本的主题应该是“PostgreSQL12：现在更稳定了”—这当然不是坏事情当你为你的业务管理任务关键型数据的时候。

而且，我相信这个版本还有更多功能的好处：PostgreSQL 12的很多特性和更能提升只会让你的应用运行的更好,因为不用做任何工作除了升级！

（而且可能会重建你的索引，多亏了这个版本，它不像以前用起来那么痛苦了）！

升级PostgreSQL并看到性能改进是非常好的，除了升级本身不用做其他任何工作。几年前，当我分析PostgreSQL9.4升级到PostgreSQL10的时候，我测量到我的底层应用程序性能执行速度快得多：它利用了PostgreSQL10引入的查询并行性改进。得到这些性能提升几乎不用我付出任何努力（在本例中，我设置max_parallel_works参数配置）。

通过简单的升级让应用更好的工作对用户来说是一种令人愉快的体验，随着越来越多的人采用PostgreSQL，让现有的用户满意是很重要的。

所以，PostgreSQL12如何通过升级让您的应用更好的工作？请继续读下去！

索引的主要改进

索引是任何数据库的关键部分：它促进了信息的快速检索。PostgreSQL使用的默认索引类型是B树，这是一种针对存储系统进行优化的索引类型。

很容易将语句CREATE INDEX ON some_table（some_column）视为理所当然的；因为PostgreSQL做了很多工作来保持索引最新，因为它存储的值是不断的插入，修改，删除的。通常情况下，它看起来就是有效的。

然而，PostgreSQL索引的一个问题是它可能膨胀，并占用很多额外的磁盘空间，这也会导致检索和更新数据时的性能下降。所谓膨胀，我是说如何维持索引结构的低效，这可能和删除的垃圾元组有关，也可能无关。（为此向彼得·盖根提供提示 ）。在索引被大量修改的工作负载上，索引膨胀可能会非常明显。

PostgreSQL 12对B树索引工作方式上进行了重大改进，而且从使用TPC-C类似的实验中，展示了空间平均利用率减少40%的效果。它不仅减少了维护B树索引（写操作）花费的时间，而且在数据怎样快速的被检索到提供了好处，这都是由于索引总体上小的多。

在表中做大量更新的应用，特别是OLTP（“online transaction processing”）范围内的应用应该注意到了磁盘利用率的提升和查询性能的提升。较低的磁盘利用率意味着在你升级你的基础结构之前你的数据库有更多的空间去准备。

基于你的升级策略，你可能需要重建B树索引来获得这些性能提升（比如，pg_upgrade 不会自动重建索引），在PostgreSQL先前的版本中，如果你的表中有大量的索引，可能会导致一个标志性的低性能事件因为一张表中的一个索引进行新建会阻塞所有修改操作。但是在PostgreSQL12中有另外一种方法：现在你可以用 REINDEX CONCURRENTLY 命令同时重建索引，所以现在你可以在没有潜在停机时间的情况下重建索引！

还有索引结构的其他部分在PostgreSQL 12中得到了改进。其中的一点是由于“just work”类别中的一项涉及到了预写日志也就是WAL。预写日志有很重要的功能，它记录着PostgreSQL数据库中发生的每一个事务，这是宕机安全和复制的一个至关重要的特征。预写日志还用在应用归档和基于时间点恢复。预写日志还意味着需要将其他信息写入磁盘，这可能会影响性能。

PostgreSQL12减少了构建索引时由GiST，GIN，和SP-GiST索引产生WAL记录的开销。这具有很多明显的好处，包括这些WAL记录所需的磁盘空间更少，并且这些数据的重放速度更快，比如在宕机恢复或基于时间点恢复期间。如果你在应用程序中使用了任何一种索引的话（比如，由PostGIS支持的地理类型的应用程序大量使用的GiST索引类型），这是另外一个无需你移动手指就能提升性能的另一个功能。

分区更大，更好，更快

PostgreSQL10介绍了声明性分区。PostgreSQL11让这个功能更容易使用。PostgreSQL12让你真正扩展分区。

PostgreSQL12对分区系统进行了显著的性能改进，特别是它处理具有数千个分区的表。比如，一个查询只影响包含数千个分区的表中的几个分区，执行速度会明显加快。除了在这些类型的查询上看到的性能改进外，你应该会注意到具有很多分区的表中的插入速度也更快。

用COPY命令写是一种好方法对于已分区的表的大多数数据加载（这有个例子 JSON ingestion ），它还是PostgreSQL12的一个推动。使用COPY已经很快；PostgreSQL12使写操作更快。

以上这些使在PostgreSQL中存储更大的数据集成为可能，它应该只是做它的工作啊却使数据更容易检索甚至还要好。应用程序越来越有划分多个分区的趋势，比如时间类型的数据，应该能注意到只是升级就能使性能取得显著提升。

虽然PostgreSQL12并不能广泛地归入到“仅通过升级使PostgreSQL更好”类别，但它允许创建引用已分区表的外键，从而消除你在分区时可能遇到的“难题”。

查询得到了显著的改进

当递归被提及时（也叫CTE或WITH查询）我迫不及待地写了篇这对PostgreSQL应用程序开发人员有多大的意义的文章。这是你能看到的你的应用程序变得更快的特征之一，如果你使用CTE的话。

我经常发现刚接触SQL的开发人员很喜欢使用CTE：如果你以某种方式编写CTE，它会让你感觉你正在写命令式的程序。我还喜欢不用CTE重写这些查询并演示性能提升，哎，这些日子已经一去不复返了。

PostgreSQL12现在允许内联某种类型的CTE，即没有副作用（SELECT）的CTE,稍后在查询中只使用一次。如果我收集了我要重写的使用CTE的查询数量的统计数据，那么大多数都可归入这种类型。这会帮助程序开发人员写的代码更易读，现在也会是性能良好的代码。

更好的是PostgreSQL12将优化此SQL的执行,而不用你去做其他额外的工作。虽然我可能不再需要优化这种类型的查询模式，但PostgreSQL继续优化它的查询工作当然更好。

JIT现在是默认设置

对于支持LLVMPostgreSQL12系统，默认情况下启用即时编译，也叫”JIT“。除了为内部系统提供JIT支持外，在选择列表中具有表达式（例如：x+y, 这是一个简单的表达式）的查询（例如：在SELECT之后编写的内容）使用聚合，WHERE子句和其他语句中的表达式可以利用JIT来提高性能。

由于JIT在PostgreSQL 12中是默认启用的，因此你可以在不用做任何事情的情况下看到性能的显著提升，但是我建议在引入JIT的PostgreSQL 11中测试你的应用程序，以衡量你的查询的执行情况并观察是否需要做任何调优。

PostgreSQL 12中还有哪些新特性？

PostgreSQL12中有很多让我真正兴奋的新特性，从使用标准SQL路径表达式自省JSON数据的能力，到使用 clientcert=verify-full设置可用的多因素身份验证类型，再到生成的列，等等。这是些不同的博客帖子。

就像我使用PostgreSQL 10的经验一样，我相信PostgreSQL 12提供了类似的能力，只需升级就能提升性能。当然，你的里程可能会有所不同：正如我对PostgreSQL 10做升级那样，在进行切换之前应该在类似的生茶环境下做测试。即使PostgreSQL 12 像我建议的那样“现在更稳定了”，你也应该在将应用程序投入生产之前进行广泛的测试。