JITコンパイラ──実行時に処理を先にコンパイルする
PostgreSQL 11では,
JITコンパイラの使い方
JITコンパイラの利用の有無は,postgresql.
で設定します。デフォルトでは無効です。
先述したとおり,
任意のタイミングで利用したい場合は,
- jit_
optimize_ above_ cost - JITコンパイル時に最適化するかどうかを決めるコストの閾値を指定する。デフォルト値は500000
- jit_
inline_ above_ cost - JITコンパイル時にインライン化を行うかどうかを決めるコストの閾値を指定する。デフォルト値は500000
があります。基本的に変更することは少ないでしょうが,
それでは,on
にするとともに,10
に下げて利用してみましょう。一時的な値の変更ですので,
図6 JITコンパイラを利用した際の実行計画
通常の実行計画 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コンパイラが使われた場合,
表2 JITコンパイラの実行計画の主な項目
名前 | 説明 |
---|---|
Functions | JITコンパイラで処理された箇所の数 |
Options: Inlining | JITコンパイル時にインライン化をしたか |
Options: Optimization | JITコンパイル時に最適化をしたか |
Timing: Generation | JITコンパイルの所要時間 |
Timing: Inlining | JITコンパイルでのインライン化の所要時間 |
Timing: Optimization | JITコンパイルでの最適化の所要時間 |
Timing: Emission | JITコンパイラのコード出力の所要時間 |
単純にExecution Timeを見ると,
JITコンパイラの使いどころ
図6のExecution Timeからわかるとおり,
では,
複雑な分析クエリや大きなテーブルに対するキャストや文字列加工が必要な場合は,
パラレルクエリ──並列実行で高速化
PostgreSQLの大きな魅力と言えば,
パラレルクエリの役割
パラレルクエリは図7のとおり,
パラレルクエリの使い方
パラレルクエリはデフォルトで有効となっており,
実際の実行計画を見てみましょう。図8のとおり,
図8 パラレルクエリの実行計画
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コンパイラほどではありませんが,
- 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_
にするとパラレルクエリを利用できます。force_
また,
パラレルクエリの対象
先述したようにパラレルクエリはPostgreSQL 9.
それがPostgreSQL 10,
- 10で追加されたパラレルクエリの対象
- Parallel Index Scan
(b-treeのみ) - Parallel Index Only Scan
(b-treeのみ) - サブクエリ
- Merge Join
- Parallel bitmap heap scan
- Parallel Index Scan
- 11で追加されたパラレルクエリの対象
- Parallel Hash Join
(9. 6からより強化) - CREATE TABLE AS SELECT
- CREATE MATERIALIZED VIEW
- UNION ALLによるAPPEND
- SELECT INTO
- CREATE INDEX
- Parallel Hash Join
一般的に利用する参照部分は,
また,
まとめ
本章では,
本誌最新号をチェック!
WEB+DB PRESS Vol.121
2021年2月22日発売
B5判/
定価
ISBN978-4-297-11960-7
- 特集1
[さらに速く! さらに書きやすく!]
詳解Ruby 3
JITコンパイラ,並列プログラミング, 静的型解析 - 特集2
UIKit,SwiftUI, iPadOS, ウィジェット
iOS 14最前線 - 特集3
個人と組織の目標がリンクする管理手法
OKR運用指南