，“世界上最好的开源关系数据库”的最新版本将在几周内发布（如果一切按计划进行）。 这遵循了每年一次发布具有大量新功能的新版本的通常时间表，坦率地说，这令人印象深刻。 这就是我成为 PostgreSQL 社区活跃成员的原因。
在我看来，与以前的版本不同，PostgreSQL 12 不包含一两个革命性功能（例如分区或查询并行性）。 我曾经开玩笑说，PostgreSQL 12的主要特点是稳定性更高。 这难道不是您管理业务关键数据时所需要的吗？
但 PostgreSQL 12 并不止于此：通过新功能和改进，应用程序将表现得更好， 您所需要做的就是升级！
（好吧，也许重建索引，但在这个版本中，它并不像我们习惯的那么可怕。）
升级 PostgreSQL 并立即享受重大改进而无需不必要的麻烦，这将是很棒的事情。 几年前，我回顾了从 PostgreSQL 9.4 到 PostgreSQL 10 的升级，并看到由于 PostgreSQL 10 中改进的查询并行性，应用程序的速度如何加快。最重要的是，我几乎不需要做任何事情（只需设置一个配置参数） max_parallel_workers).
同意，当应用程序在升级后立即运行得更好时，这很方便。 我们非常努力地取悦用户，因为 PostgreSQL 的用户越来越多。
那么简单升级到 PostgreSQL 12 如何能让您满意呢？ 我现在就告诉你。
主要索引改进
没有索引，数据库就走不远。 还有什么方法可以快速找到信息呢？ PostgreSQL 的基本索引系统称为 。 这种类型的索引针对存储系统进行了优化。
我们只需使用运算符 CREATE INDEX ON some_table (some_column)，当我们不断插入、更新和删除值时，PostgreSQL 做了很多工作来保持索引最新。 一切都像魔术一样自行运作。
但 PostgreSQL 索引有一个问题 - 它们 并占用额外的磁盘空间并降低数据检索和更新的性能。 我所说的“膨胀”是指无效地维护索引结构。 这可能与它删除的垃圾元组有关，也可能无关 （感谢彼得·加根提供的信息）））。 在索引主动变化的工作负载中，索引膨胀尤其明显。
PostgreSQL 12 极大地提高了 B 树索引的性能，TPC-C 等基准测试的实验表明，现在使用的空间平均减少了 40%。 现在，我们不仅花在维护 B 树索引（即写操作）上的时间更少，而且花在检索数据上的时间也更少，因为索引小得多。
主动更新其表的应用程序 - 通常是 OLTP 应用程序（) - 将更有效地使用磁盘和处理请求。 磁盘空间越多，数据库在不升级基础设施的情况下需要增长的空间就越大。
某些升级策略需要重建 B 树索引才能利用这些优势（例如 不会自动重建索引）。 在 PostgreSQL 的早期版本中，重建表上的大型索引会导致严重的停机时间，因为同时无法进行更改。 但 PostgreSQL 12 还有另一个很酷的功能：现在您可以与命令并行重建索引 以完全避免停机。
PostgreSQL 12 中的索引基础设施还有其他改进。 另一件事也有一些魔力—— ，又名 WAL（预写日志）。 预写日志记录 PostgreSQL 中的每个事务，以防发生故障和复制。 应用程序使用它来归档和 。 当然，预写日志会写入磁盘，这会影响性能。
PostgreSQL 12 减少了索引构建期间由 GiST、GIN 和 SP-GiST 索引创建的 WAL 记录的开销。 这提供了几个切实的好处：WAL 记录占用更少的磁盘空间，并且数据重播速度更快，例如在灾难恢复或时间点恢复期间。 如果您在应用程序中使用此类索引（例如，基于 PostGIS 的地理空间应用程序大量使用 GiST 索引），那么这是另一个无需您付出任何努力即可显着改善体验的功能。
分区 - 更大、更好、更快
PostgreSQL 10 推出 。 在 PostgreSQL 11 中，它变得更容易使用。 在 PostgreSQL 12 中，您可以更改部分的比例。
在 PostgreSQL 12 中，分区系统的性能显着提高，尤其是在表中有数千个分区的情况下。 例如，如果一个查询只影响一个有数千个分区的表中的几个分区，那么它的执行速度会快得多。 性能的提高不仅仅针对这些类型的查询。 您还会注意到在具有多个分区的表上执行 INSERT 操作的速度有多快。
记录数据使用 - 顺便说一下，这是一个很好的方法 这是一个例子 — PostgreSQL 12 中的分区表也变得更加高效。 使用 COPY 一切都已经很快了，但在 PostgreSQL 12 中它绝对是飞速的。
由于这些优点，PostgreSQL 允许您存储更大的数据集并使它们更容易检索。 而你却没有付出任何努力。 如果应用程序有很多分区，例如记录时间序列数据，简单的升级将显着提高其性能。
虽然这不完全是“升级并享受”的改进，但 PostgreSQL 12 允许您创建引用分区表的外键，使分区成为一种愉快的工作。
WITH 查询变得更好了
何时 （又名 CTE，又名WITH查询），我迫不及待地想写一篇关于 。 这是可以加快应用程序速度的功能之一。 当然，除非您使用 CTE。
我经常发现 SQL 新手喜欢使用 CTE；如果你以某种方式编写它们，感觉就像你在编写一个命令式程序。 就我个人而言，我喜欢重写这些查询来解决 无 CTE 并提高生产率。 现在一切都不同了。
PostgreSQL 12 允许您内联特定类型的 CTE，而不会产生副作用（SELECT)，仅在请求结束时使用一次。 如果我跟踪我重写的 CTE 查询，其中大多数都属于这一类。 这有助于开发人员编写清晰的代码，并且现在也可以快速运行。
此外，PostgreSQL 12 本身优化了 SQL 执行，而无需您执行任何操作。 虽然我现在可能不需要优化此类查询，但 PostgreSQL 继续致力于查询优化真是太好了。
即时 (JIT) - 现在默认
在支持的 PostgreSQL 12 系统上 默认情况下启用 JIT 编译。 首先，你会得到支持 对于一些内部操作，其次，在选择列表（SELECT 之后的）中使用表达式（最简单的例子是 x + y）、聚合、带有 WHERE 子句的表达式等的查询可以使用 JIT 来提高性能。
由于 PostgreSQL 12 中默认启用 JIT，因此性能会自行提高，但我建议在引入了 JIT 的 PostgreSQL 11 中测试应用程序，以测量查询性能并查看是否需要调整任何内容。
PostgreSQL 12 中的其他新功能怎么样？
PostgreSQL 12 拥有大量很酷的新功能，从使用标准 SQL/JSON 路由表达式检查 JSON 数据的能力到使用参数的多重身份验证 clientcert=verify-full、创建专栏等等。 足够单独发表一篇文章了。
与 PostgreSQL 10 一样，PostgreSQL 12 在升级后将立即提高整体性能。 当然，您可以有自己的路径 - 在启用改进之前在生产系统上的类似条件下测试应用程序，就像我对 PostgreSQL 10 所做的那样。即使 PostgreSQL 12 已经比我预期的更稳定，也不要懒于测试在将应用程序投入生产之前，对其进行彻底的检查。
来源： habr.com