【PostgreSQL 架构】PostgreSQL 11和即时编译查询

【PostgreSQL 架构】PostgreSQL 11和即时编译查询

PostgreSQL 11正在酝酿之中，即将发布。同时，使用您自己的应用程序对其进行测试是确保社区在零点发行之前捕获所有剩余错误的好方法。

下一个PostgreSQL版本的重大变化之一是Andres Freund在查询执行器引擎上的工作成果。Andres已经在系统的这一部分上工作了一段时间，在下一发行版中，我们将看到执行引擎中的一个新组件：一个JIT表达式编译器！

基准和TPC-H

我喜欢在Citus Data进行工程工作以通过Citus扩展扩展PostgreSQL的一件事就是，我可以运行基准测试！基准测试是一个很好的工具，可以显示性能改进可带来哪些好处。当前，JIT表达式编译器在以下情况下效果最佳：

该查询包含多个复杂的表达式，例如聚合。该查询读取了大量数据，但没有IO资源短缺。该查询非常复杂，以至于需要花费大量的JIT精力。

通过主键代理ID获取某些信息的查询不太适合查看PostgreSQL中新的JIT基础结构所提供的改进。

TPC-H基准测试第1季度查询可以很好地评估新执行程序堆栈的影响，因此我们在这里使用它。

基准测试的规范可在137页的名为TPC Benchmark™H的PDF文档中找到。该规范中的每个查询都附带一个业务问题，因此请参阅第一季度

定价摘要报告查询（Q1）

此查询报告已开票，发货和退回的业务量。

定价摘要报告查询提供了给定日期发货的所有订单项的摘要定价报告。该日期位于数据库中包含的最晚发货日期的60-120天之内。该查询列出了扩展价格，折扣扩展价格，折扣扩展价格加税，平均数量，平均扩展价格和平均折扣的总计。这些聚合按RETURNFLAG和LINESTATUS分组，并按RETURNFLAG和LINESTATUS的升序排列。包括每个组中的行项目数的计数。

这就是SQL中的样子：

select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty, sum(l_extendedprice) as sum_base_price, sum(l_extendedprice * (1 - l_discount)) as sum_disc_price, sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge, avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price, avg(l_discount) as avg_disc, count(*) as count_order from lineitem where l_shipdate <= date '1998-12-01' - interval ':1' day group by l_returnflag, l_linestatus order by l_returnflag, l_linestatus :n -1 ;

此外，该规范还提供有关查询的注释：

注释：1998-12-01是数据库填充中定义的最高可能的发货日期。（这是ENDDATE-30）。该查询将包括该日期之前减去DELTA天之前发货的所有订单项。目的是选择DELTA，以便扫描表中95％至97％的行。

为了使查询有资格显示新的PostgreSQL表达式以执行JIT编译器，我们将选择适合内存的比例因子。

结果

选择10的比例因子时，我们得到的数据库大小为22GB，包括创建的索引。此处使用的完整架构在tpch-schema.sql上可用，而索引在tpch-pkeys.sql和tpch-index.sql上。

在我的测试中，执行TPCH Q1查询时，PostgreSQL 11比PostgreSQL 10快29.31％。在循环中运行查询10分钟时，当PostgreSQL 10仅执行同一查询时，它允许PostgreSQL 11执行30次。21次。

如我们所见，PostgreSQL 10中的Andres工作已经对该查询产生了巨大影响。在此版本中，对执行程序的表达式评估进行了全面修订，以考虑到CPU缓存行和指令管道。在此基准测试中，我们选择在PostgreSQL中禁用并行查询，以便评估主要由新执行程序导致的改进。PostgreSQL 10 then 11中的并行支持能够大大增强我们在此看到的查询时间！

在PostgreSQL 11中，由于在查询计划时使用LLVM编译器基础结构，SQL表达式已转换为机器代码，这对查询性能产生了另一个非常好的影响！

工具

基准测试规范有两个文件可用：

llvm-q1-infra.ini定义了用于运行此测试的AWS EC2实例。

在这里您可以看到我们选择了c5.4xlarge实例来托管我们的PostgreSQL数据库。它们每个都有30GB的RAM，因此我们的22GB数据集和索引非常适合RAM。另外，我们使用11开发快照。

llvm-q1-schedule.ini定义了我们的基准计划，这在这里非常简单：

[schedule]full = initdb, single-user-stream, multi-user-stream

在initdb阶段，在8个并发进程中加载比例因子10的数据，每个进程一次执行一个步骤，考虑到我们将工作负载分为10个子进程。我们在这里使用TPC-H s语。另外，在我研究的PostgreSQL的TPC-H实现中，我增加了对直接加载机制的支持，这意味着dbgen工具连接到数据库服务器并使用COPY协议。然后执行一个单用户流，该流包括在客户端的单个CPU上运行尽可能多的查询，并持续10分钟。然后执行一个多用户流，该流包含从所有8个CPU并行运行尽可能多的查询，并持续10分钟。

此处使用的基准测试工具是“开源”，可从EC2基础架构中运行TPCH。

这个想法是，在创建几个配置文件后，可以在多个系统上并行驱动一个完整的基准测试，并在合并的数据库中检索结果以供以后分析。

此外，该项目还包括适用于PostgreSQL的TPCH C代码版本，并使用COPY协议实现直接加载。然后，该项目使用dbgen工具生成数据，并使用qgen工具为每个客户端根据规范生成新的查询流。

期待未来的Postgres

PostgreSQL 11引入了一个新的PostgreSQL执行引擎，借助LLVM框架，该引擎将您的SQL代码编译为机器代码。对于足够昂贵的查询（遍历许多行并一次又一次地计算表达式的查询），其好处可能是巨大的！

在我们的基准测试中，PostgreSQL 11 JIT是一项很棒的技术，它提供了高达29.31％的速度改进，在使用PostgreSQL 10时以20.5s的比例因子10执行TPC-H Q1而不是29s。

在Citus，我们几个月来一直在忙于针对PostgreSQL测试Citus扩展。因为Citus是Postgres的纯粹扩展，而不是fork，这意味着当时候到来时，您应该能够升级以获得Postgres 11的所有新优势，以帮助您保持扩展。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。