JITコンパイラ─⁠─実行時に処理を先にコンパイルする

PostgreSQL 11では，なんとLLVM（Low Level Virtual Machine，低水準仮想マシン）による実行時コンパイラ，つまりJITコンパイラが追加されています。JITコンパイラが効果的なシーンは，計算量が多く，CPUがボトルネックになっており，長時間実行されるようなSQL文です。逆に小さな処理では，オーバーヘッドのほうが大きくなります。

JITコンパイラの使い方

JITコンパイラの利用の有無は，postgresql.confで設定します。デフォルトでは無効です。

先述したとおり，JITコンパイラは大きな処理でなければ非効率になります。そのため有効になっている場合も，実行計画で推定されたコストがjit_above_costの閾値（いきち）（デフォルト値は100000）を超えるSQLのみ，JITコンパイラが実行されます。この100000という閾値は簡単に超える値ではないため，基本的にはデフォルト値のままで問題ありません。

任意のタイミングで利用したい場合は，jit_above_costをチューニングしましょう。そのほかにもパラメータとして，

jit_optimize_above_cost

JITコンパイル時に最適化するかどうかを決めるコストの閾値を指定する。デフォルト値は500000

jit_inline_above_cost

JITコンパイル時にインライン化を行うかどうかを決めるコストの閾値を指定する。デフォルト値は500000

があります。基本的に変更することは少ないでしょうが，JITコンパイラのチューニングの際には必要になりますので，覚えておきましょう。

それでは，実際にJITコンパイラを使ってみましょう。先述したとおり，JITコンパイラはデフォルトで無効化されており，気軽に試せる閾値にもなっていません。そこで図6のように，JITコンパイラをonにするとともに，jit_above_costを10に下げて利用してみましょう。一時的な値の変更ですので，図6ではSET文で変更しています。

通常の実行計画

demo=# EXPLAIN ANALYZE SELECT SUM(relpages) FROM pg_class;
                                                 QUERY PLAN
-------------------------------------------------------------------------------------------------
 Aggregate (cost=16.27..16.29 rows=1 width=8) (actual time=0.236..0.236 rows=1 loops=1)
   -> Seq Scan on pg_class (cost=0.00..15.42 rows=342 width=4) (actual time=0.008..0.122 rows=342 loops=1)
 Planning Time: 3.317 ms
 Execution Time: 0.485 ms
(4 rows)

JITコンパイラが利用された場合の実行計画
demo=# SET jit TO on;
demo=# SET jit_above_cost TO 10;

demo=# EXPLAIN ANALYZE SELECT SUM(relpages) FROM pg_class;
                                                 QUERY PLAN
------------------------------------------------------------------------------------------------
 Aggregate (cost=16.27..16.29 rows=1 width=8) (actual time=9.850..9.850 rows=1 loops=1)
   -> Seq Scan on pg_class (cost=0.00..15.42 rows=342 width=4) (actual time=0.014..0.066 rows=342 loops=1)
 Planning Time: 0.132 ms
 JIT:
   Functions: 3
   Options: Inlining false, Optimization false, Expressions true, Deforming true
   Timing: Generation 0.894 ms, Inlining 0.000 ms, Optimization 0.652 ms, Emission 8.867 ms, Total 10.414 ms
 Execution Time: 114.956 ms
(8 rows)

JITコンパイラが使われた場合，コンパイルの時間なども実行計画に出力されます。JITコンパイラの実行計画を見るうえ主な項目は表2のとおりです。JITコンパイラをチューニングする場合は，これらの項目を見ながら調整しましょう。

単純にExecution Timeを見ると，JITコンパイラの利用の有無でどちらが有効であるかを比較できます。

JITコンパイラの使いどころ

図6のExecution Timeからわかるとおり，小さな処理ではJITコンパイラは逆に遅くなります。

では，実際にどの程度の処理からJITコンパイラの効果があるのでしょうか。「⁠SRA OSS Tech Blog」の「PostgreSQL 11検証報告」によると，およそ11の関数や演算子と3ヵ所以上のキャストがあり，1億件以上の行に対して処理するようなSQLの場合に効果が出るようです。

複雑な分析クエリや大きなテーブルに対するキャストや文字列加工が必要な場合は，JITコンパイラの利用を検討してもよいでしょう。また，JITコンパイラは11から入った新機能ですので，今後より進化していくことでしょう。

パラレルクエリ─⁠─並列実行で高速化

PostgreSQLの大きな魅力と言えば，9.6から採用されたパラレルクエリです。パラレルクエリを使うと，複雑な集計クエリなどを並列処理し，高速に行えます。この機能はマルチコアCPU時代にマッチした強力な機能です。

パラレルクエリの役割

パラレルクエリは図7のとおり，テーブルスキャンなどの読み込みに対して並列に処理し，計算結果を最後に結合して返すしくみです。テーブルスキャンの場合などは対象テーブルが大きければ大きいほど効果が出ますし，並列度をうまくチューニングできれば処理速度も数倍速くなります。

パラレルクエリの使い方

パラレルクエリはデフォルトで有効となっており，意識しなくても利用条件を満たせば自動的に使われます。

実際の実行計画を見てみましょう。図8のとおり，RDBMSの宿敵とも言えるテーブルスキャンを高速に処理できます。

10,000,000行のテストデータに対する実行
demo=# EXPLAIN ANALYZE SELECT id FROM t1 WHERE id % 3 = 0;
                                            QUERY PLAN
-------------------------------------------------------------------------------------------------
Gather (cost=1000.00..151833.03 rows=49999 width=4) (actual time=0.374..2555.601 rows=3333333 loops=1)
  Workers Planned: 2
  Workers Launched: 2
  -> Parallel Seq Scan on t1 (cost=0.00..145833.13 rows=20833 width=4) (actual time=0.048..785.725 rows=1111111 loops=3)
       Filter: ((id % 3) = 0)
       Rows Removed by Filter: 2222222
 Planning Time: 0.168 ms
 Execution Time: 2873.127 ms

JITコンパイラほどではありませんが，パラレルクエリも小さなテーブルでは並列化のメリットよりオーバーヘッドのほうが問題になります。そのため，JITコンパイラと同様に，パラレルクエリを利用する閾値を指定します。パラレルクエリのパラメータは次のとおりです。

max_worker_processes

システム全体で起動できるバックグランドワーカの上限数。これにはパラレルワーカも含み，たとえば設定値が8の場合に，自分が定義したバックグランドワーカを4つ起動させると，パラレルワーカは最大4つしか起動しない。デフォルト値は8

max_parallel_workers_per_gather

パラレルクエリ処理中に起動できるパラレルワーカの上限数。設定値が0の場合，パラレルクエリは実行されない。デフォルト値は2

max_parallel_workers

システム全体で起動できるパラレルワーカの上限数。max_worker_processesの設定値を超えることはできない。デフォルト値は8

parallel_tuple_cost

パラレル処理時にほかのプロセスにデータを受け渡しするのに必要なコストに対するプランナの推測値。デフォルト値は0.1

parallel_setup_cost

パラレル処理を行うプロセスを起動するのに必要なコストに対するプランナの推測値。デフォルト値は1000

min_parallel_table_scan_size

テーブルの参照対象が設定値以上だとパラレルワーカを追加起動する。デフォルト値は8MB

min_parallel_index_scan_size

インデックスの参照対象が設定値以上だとパラレルワーカを追加起動する。デフォルト値は512KB

テストや使うべきと事前にわかっているアドホックなクエリを実行する場合は，force_parallel_mode=onにするとパラレルクエリを利用できます。force_parallel_modeはSET文で設定することもできます。

また，パラレルクエリのワーカ数は一般的にCPUの数と同様にするのが望ましいです。ワーカ数を増やして並列度を上げたい場合は，CPUのコア数が多いサーバを用意しましょう。

パラレルクエリの対象

先述したようにパラレルクエリはPostgreSQL 9.6からありましたが，インデックスを活用できなかったため，対象がテーブルスキャンで実行されるHashJoinやNested Loop Join，集約などのみでした。実際の多くのクエリはインデックスを利用するため，パラレルクエリを活用できるケースは限られていました。

それがPostgreSQL 10，11とバージョンが上がるたびに拡張され，今では多くのケースで実行されます。

10で追加されたパラレルクエリの対象

• Parallel Index Scan（b-treeのみ）
• Parallel Index Only Scan（b-treeのみ）
• サブクエリ
• Merge Join
• Parallel bitmap heap scan

11で追加されたパラレルクエリの対象

• Parallel Hash Join（9.6からより強化）
• CREATE TABLE AS SELECT
• CREATE MATERIALIZED VIEW
• UNION ALLによるAPPEND
• SELECT INTO
• CREATE INDEX

一般的に利用する参照部分は，PostgreSQL 11でパラレルクエリの対象になったと言えます。特にJOINやインデックスは日常的に利用されるクエリであるため，パラレルクエリの恩恵を受けることが多いでしょう。

また，パラレルクエリはMySQLにはなく，OSSDBの中でPostgreSQLが大きな優位性を持っている機能の一つです。

まとめ

本章では，PostgreSQLの開発者向けの機能を紹介しました。PostgreSQL 10，11では，今までアプリケーションで四苦八苦してチューニングしたり，シャーディングしていたような問題がRDBMSの機能で対応できるようになっています。これを機に新しいPostgreSQLを使って設計の幅を広げていきましょう。

本誌最新号をチェック！
WEB+DB PRESS Vol.118

2020年8月24日発売
B5判／176ページ
定価（本体1,480円＋税）
ISBN978-4-297-11566-1

• 特集1
  開発環境の整備，効果的な議論，評価制度
  実践リモートワーク
  オフィスに集まれない課題の解消方法
• 特集2
  Pythonデータ可視化入門
  COVID-19／家計調査／財政データで実践！
• 特集3
  ツールで簡単！
  はじめての脆弱性調査
  Rails，nginx，サブドメイン，DB，OpenSSL