はじめに

2018/10/18、PostgreSQL 11がリリースされました。

PostgreSQL 11 Released
https://www.postgresql.org/about/news/1894/

パラレルクエリやパーティショニングの強化など、大規模データベース向けの様々な機能が強化されています。
今回はその中でも個人的に注目している&なにげに構築が難しい、JITコンパイル機能について検証した内容を共有しようと思います。

本記事を執筆するに辺り、様々な情報を参考にし、そのリンク先を載せています。
しかし一部のリンク先は、PostgreSQL 11ベータ版における検証情報です。
正式にリリースされたPostgreSQL 11とは結果が異なる可能性があるためご注意ください。

JITコンパイルの導入

PostgreSQL 11を普通に導入しても、JITコンパイルが使えるとは限りません。
デフォルトでは未導入のライブラリ等をインストールする必要があります。

ソースコードからPostgreSQLを構築する場合

ソースコードからPostgreSQLを構築する場合、事前にLLVMを導入する必要があります。
(CentOS7等はLLVMがデフォルトで導入されていますが、バージョンが古いため対応が必要です)

またコンパイル時に、LLVMを使用することをオプションで明示的にする必要があります。

ソースコードからの構築＋LLVMの導入は参考にしたサイトの構築・検証系に詳しく載っています。
ただし、下記の情報はPostgreSQL 11のベータ版における情報です。
現在は、必要なLLVMのバージョンが上がっている可能性があるため注意ください。

RPMからPostgreSQLを構築する場合

RPMからのPostgreSQL導入については以前、記事を書いています(ダイマ)。
詳細な導入手順についてはこの記事をご参照ください。
初心者からこだわりのある人向けRPMからPostgreSQL導入

オンライン環境の場合

上記記事で紹介しているRPMからのPostgreSQL導入により、JIT対応のビルドを利用できます。
ただしOS側のLLVMのバージョンが、適切できない可能性があるため、注意が必要です。

LLVMのバージョンアップ方法は参考にしたサイトの構築・検証系で紹介したリンク先に案内されています。

オフライン環境の場合

LLVMはEPEL(Linux用拡張パッケージ)から入手できます。
今回は5.0以上のバージョンを入手します。

EPEL/ja
https://fedoraproject.org/wiki/EPEL/ja

オフライン環境の場合、直接必要なRPMを上記のサイトから入手し、導入先の環境に配置します。

例)CentOS 7の場合
https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/l/
↑から「llvm5.0-libs-5.0.1-7.el7.x86_64.rpm」と「llvm5.0-5.0.1-7.el7.x86_64.rpm」を入手する。

yum install llvm5.0-libs-5.0.1-7.el7.x86_64.rpm
yum install llvm5.0-5.0.1-7.el7.x86_64.rpm

これによりLLVMの導入が完了しました。
次はPostgreSQLのLLVM用のRPMを導入します。
以下のサイトから、適切なOS行におけるバージョンの数字をクリックすることで、PostgreSQL関連の全てのRPMが確認できます。
そこからLLVM関連のRPMを入手します。

PostgreSQL RPM Chart
https://yum.postgresql.org/rpmchart.php

例)CentOS 7環境におけるPostgreSQL 11の場合
https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-7.4-x86_64/
↑から「postgresql11-llvmjit-11.0-1PGDG.rhel7.x86_64.rpm」を入手する。

yum install postgresql11-llvmjit-11.0-1PGDG.rhel7.x86_64.rpm

これによりJITコンパイルが利用可能な環境になりました。

実際に使ってみよう

JITコンパイルが利用可能な状態になっても、すぐ使える訳ではありません。
関連するパラメータを調整する必要があります。

パラメータについてはマニュアルとPostgreSQL11がやってくる！(1) - パラメータの差異の記事を参考にさせていただきました。
JIT関連以外にも、PostgreSQL 11で追加/変更されたパラメータの説明があるため、PostgreSQL関係者は必見です。
また(1)とあるように、執筆者である、ぬこ＠横浜様は11に関する様々な記事を投稿しています。
私自身、PostgreSQL 11検証で参考にしているのでオススメです(ダイマその2)。

JIT関連のパラメータ

JITコンパイルを使用するために必要なパラメータ群です。
特にjit_above_cost、jit_inline_above_cost、jit_optimize_above_costの3つは関連性が強いです。
これらのパラメータを変更し、JITコンパイルを適切に使用します。

パラメータ名	デフォルト値	説明
jit	off	JITコンパイルの使用可能にするかを決めます。ベータ版ではデフォルトでonでしたが、正式版ではoffがデフォルトです。
jit_above_cost	100000	JITコンパイルが使用されるかを決めるコストの閾値です。クエリの推定コストが本値を超えると使用されます。値が-1の場合、無効化されます。
jit_inline_above_cost	500000	JITコンパイル使用後に、インライン展開するかを決める閾値です。 JITコンパイルのオーバヘッドは増加しますが、クエリ実行時間は減ります。クエリの推定コストが本値を超えると使用されます。値が-1の場合、無効化されます。
jit_optimize_above_cost	500000	インライン展開後、高価な最適化をするか決める閾値です。 JITコンパイルのオーバヘッドは増加しますが、クエリ実行時間は減ります。クエリの推定コストが本値を超えると使用されます。値が-1の場合、無効化されます。
jit_provider	llvmjit	使用するJITプロパイダを決定します。現在はLLVMのみ対応しているため変更の必要はありません。

この他にも開発者向けのパラメータがありますが、通常運用する際には特に気にする必要はないと思います。

パラメータを変更しJITコンパイルを使ってみる

JIT関連のパラメータを見れば分かる通り、JIT使用可否の閾値を下げればJITコンパイルをとりあえず使うことはできます。

まずJITコンパイルを使用するテスト用のテーブルを作成します。

テスト用テーブル作成

CREATE TABLE jit_test (a INTEGER, b TEXT);

INSERT INTO jit_test (a, b)
SELECT g, md5(g::text) FROM generate_series(1, 50000) AS g;

次にJITコンパイルを無理やり実行するために、JITコンパイルを有効化し、関連パラメータの閾値を下げます。

パラメータを調整

SET jit=on;
SET jit_above_cost=10;
SET jit_inline_above_cost=10;
SET jit_optimize_above_cost=10;

これによりJITコンパイルを使用する準備が出来ました。
PostgreSQL 11現在、JITコンパイルはWHERE句や集計等のために使用されます。
(詳細はマニュアルの以下の部分をご参照ください)

32.1.1. JIT Accelerated Operations
https://www.postgresql.org/docs/11/static/jit-reason.html#JIT-ACCELERATED-OPERATIONS

そのため適当なWHERE句を付けて、SQL文を実行し、その実行計画を見てみます。

JITコンパイル対象のSQL文

EXPLAIN ANALYZE SELECT * FROM jit_test WHERE a%2 = 1;

SQL文の実行結果

                                                  QUERY PLAN
---------------------------------------------------------------------------------------------------------------
 Seq Scan on jit_test  (cost=0.00..1167.00 rows=250 width=37) (actual time=71.657..77.408 rows=25000 loops=1)
   Filter: ((a % 2) = 1)
   Rows Removed by Filter: 25000
 Planning Time: 0.044 ms
 JIT:
   Functions: 2
   Options: Inlining true, Optimization true, Expressions true, Deforming true
   Timing: Generation 0.443 ms, Inlining 50.772 ms, Optimization 12.781 ms, Emission 7.972 ms, Total 71.969 ms
 Execution Time: 86.891 ms
(9 行)

「JIT:」以降の行を見れば分かるように、JITコンパイルが使用されています。
ただし今回は閾値を下げて、無理やり使用したため、JITコンパイル未使用時と比べてパフォーマンスは低下しています。
これはJITコンパイルによる高速化よりも、オーバーヘッドによるコストが上回ってしまったためです。
では実際にどのような状況でJITコンパイルが有効であるかを次項で調査・検証してみます。

性能を検証してみた

JITコンパイルによるクエリ実行は、通常のクエリ実行と比べ必ずしも高速になるとは限りません。
JITコンパイルによるオーバーヘッドによるコストが高まってしまえば、通常のクエリより遅くなります。
JITコンパイルにより高速化する主なクエリは、I/Oは問題ないが、CPUがボトルネックとなるSQLです。
言い換えると、複雑な集計や計算処理が含まれるSQL処理に適しています。

なので今回はTPC-Hベンチマークテストを使用しました。

TPC-Hベンチマークテストの導入

TPC-HベンチマークテストはTPCのサイトから入手可能です。
ただしPostgreSQL向けには設定されていないため、調整が必要です。
本記事では導入手順については割愛させていただきます。
(いつか別記事として書くかも)
詳細を知りたい方は、参考にしたサイトのTPC-HのPostgreSQL導入のリンク先をご参照ください。

今回は10GBのテストデータを用いて検証を実施しています。

テスト用データ生成

./dbgen -s 10

また検証用の環境として以下を作成しております。
(TPC-Hの用意されたSQLはTPCDスキーマ上にオブジェクトがあることが前提のため)

ロールの作成

=# CREATE ROLE tpcd;
=# ALTER ROLE tpcd LOGIN SUPERUSER CREATEROLE CREATEDB CONNECTION LIMIT -1 PASSWORD 'password';

データベースの作成

=# CREATE DATABASE tpcd OWNER tpcd;

スキーマの作成

=# \c tpcd tpcd
=# CREATE SCHEMA tpcd;

なお、検証には以下の仮想環境を用いています。

OS	メモリ	CPU
CentOS 7.4	4GB	2コア

JITコンパイルの有無による性能比較

今回はTPC-Hのクエリ1を用いて、JITコンパイル使用有無における性能を比較します。
まずはJITコンパイルを使用しなかった場合のEXPLAN ANALYZEの結果です。
デフォルトでJITの使用はOFFですが、分かりやすいように敢えてJIT=OFFの設定をしています。

JITコンパイル未使用時のTPC-Hクエリ1の実行結果

=# SET jit=off;
=# explain analyze
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
LIMIT 1;

                                                                            QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=2437688.60..2437688.94 rows=1 width=236) (actual time=68884.525..68885.261 rows=1 loops=1)
   ->  Finalize GroupAggregate  (cost=2437688.60..2437690.67 rows=6 width=236) (actual time=68884.524..68884.525 rows=1 loops=1)
         Group Key: l_returnflag, l_linestatus
         ->  Gather Merge  (cost=2437688.60..2437690.00 rows=12 width=236) (actual time=68884.493..68885.228 rows=4 loops=1)
               Workers Planned: 2
               Workers Launched: 2
               ->  Sort  (cost=2436688.57..2436688.59 rows=6 width=236) (actual time=68879.669..68879.670 rows=3 loops=3)
                     Sort Key: l_returnflag, l_linestatus
                     Sort Method: quicksort  Memory: 27kB
                     Worker 0:  Sort Method: quicksort  Memory: 27kB
                     Worker 1:  Sort Method: quicksort  Memory: 27kB
                     ->  Partial HashAggregate  (cost=2436688.33..2436688.50 rows=6 width=236) (actual time=68879.633..68879.641 rows=4 loops=3)
                           Group Key: l_returnflag, l_linestatus
                           ->  Parallel Seq Scan on lineitem  (cost=0.00..1437019.25 rows=24991727 width=25) (actual time=2.905..13461.643 rows=19995278 loops=3)
                                 Filter: (l_shipdate <= '1998-11-30 00:00:00'::timestamp without time zone)
                                 Rows Removed by Filter: 73
 Planning Time: 0.201 ms
 Execution Time: 68885.341 ms
(18 行)