PostgreSQL 11正在醞釀之中，即將發布。同時，使用您自己的應用程式對其進行測試是確保社區在零點發行之前捕獲所有剩餘錯誤的好方法。
下一個PostgreSQL版本的重大變化之一是Andres Freund在查詢執行器引擎上的工作成果。 Andres已經在系統的這一部分上工作了一段時間，在下一發行版中，我們將看到執行引擎中的一個新組件：一個JIT表達式編譯器！
基準和TPC-H
我喜歡在Citus Data進行工程工作以通過Citus擴展擴展PostgreSQL的一件事就是，我可以運行基準測試！基準測試是一個很好的工具，可以顯示性能改進可帶來哪些好處。當前，JIT表達式編譯器在以下情況下效果最佳：
- 該查詢包含多個複雜的表達式，例如聚合。
- 該查詢讀取了大量數據，但沒有IO資源短缺。
- 該查詢非常複雜，以至於需要花費大量的JIT精力。
通過主鍵代理ID獲取某些信息的查詢不太適合查看PostgreSQL中新的JIT基礎結構所提供的改進。
TPC-H基準測試第1季度查詢可以很好地評估新執行程序堆棧的影響，因此我們在這裡使用它。
基準測試的規範可在137頁的名為TPC BenchmarkH的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。
- 另外，我們使用http://apt.postgresql.org中的軟體包選擇了debian作業系統，該軟體包提供了我們在此處一直使用的PostgreSQL 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分鐘。
此處使用的基準測試工具是「開源」，可從https://github.com/dimitri/tpch-citus免費獲得。這是一個簡單的應用程式，可以自動在動態的AWS EC2基礎架構中運行TPCH。
這個想法是，在創建幾個配置文件後，可以在多個系統上並行驅動一個完整的基準測試，並在合併的資料庫中檢索結果以供以後分析。
此外，該項目還包括適用於PostgreSQL的TPCH C代碼版本，並使用COPY協議實現直接加載。然後，該項目使用dbgen工具生成數據，並使用qgen工具為每個客戶端根據規範生成新的查詢流。
期待未來的Postgres
PostgreSQL 11引入了一個新的PostgreSQL執行引擎，藉助LLVM框架，該引擎將您的SQL代碼編譯為機器代碼。對於足夠昂貴的查詢（遍歷許多行並一次又一次地計算表達式的查詢），其好處可能是巨大的！
為了幫助PostgreSQL實現版本11的最佳發行，請考慮在測試和CI環境中使用beta版本，並報告您可能會發現的所有錯誤或性能下降，並通過一種簡便的方法來再現它們。有關聲明和如何報告相關發現的詳細信息，請參見PostgreSQL 10.5和11 Beta 3 Released。
在我們的基準測試中，PostgreSQL 11 JIT是一項很棒的技術，它提供了高達29.31％的速度改進，在使用PostgreSQL 10時以20.5s的比例因子10執行TPC-H Q1而不是29s。
在Citus，我們幾個月來一直在忙於針對PostgreSQL測試Citus擴展。因為Citus是Postgres的純粹擴展，而不是fork，這意味著當時候到來時，您應該能夠升級以獲得Postgres 11的所有新優勢，以幫助您保持擴展。
原文：https://www.citusdata.com/blog/2018/09/11/postgresql-11-just-in-time/
本文：http://jiagoushi.pro/node/924
討論:請加入知識星球或者微信圈子【首席架構師圈】