PostgreSQLのJITコンパイル：その「劇薬」と付き合うためのエンジニアリング
PostgreSQLを長く触っていると、必ず一度は突き当たる壁があります。「なぜ、このクエリはこれほどまでにCPUリソースを食いつぶすのか」という問いです。
PostgreSQL 11から導入されたJIT（Just-in-Time）コンパイルは、複雑なクエリの実行計画において、まさにゲームチェンジャーでした。しかし、現場のエンジニアの間では「とりあえずオフにしておく」という判断がなされることも少なくありません。
今日は、この「劇薬」とも言えるJITコンパイルの深層を紐解き、いつ使い、いつ捨てるべきなのか、その哲学について語ってみましょう。
JITの正体：なぜ「機械語」が必要なのか
PostgreSQLのクエリ実行エンジンは、伝統的に「火山型（Volcano model）」と呼ばれるイテレータベースの設計です。これは非常に柔軟でモジュール化しやすい反面、データレコードを一行処理するたびに多くの関数呼び出し（Function Call）がスタックに積まれるというオーバーヘッドを抱えています。
単純なSELECTならまだしも、複雑な`WHERE`句の評価や、大量の計算を伴う集約関数、あるいはウィンドウ関数が絡むと、このオーバーヘッドは無視できなくなります。
ここで登場するのがLLVMです。JITコンパイルは、この「動的な式」を実行時にネイティブな機械語にコンパイルすることで、関数呼び出しのコストを削ぎ落とし、CPUのレジスタを最大限に活用するコードへ変換します。要は、「汎用的な通訳」を「その場で作る専門の機械」に入れ替えるようなものです。
パフォーマンスの「トレードオフ」を理解する
JITの恩恵は、処理すべきデータ量が膨大で、かつ計算コストが高いクエリにおいて最大化されます。しかし、ここには無視できないコストが存在します。
- コンパイル時間（Compilation Overhead）: LLVMによる最適化は無料ではありません。非常に短いクエリや、実行時間が数ミリ秒程度のクエリに対してJITを走らせると、実行速度の向上分よりも「コンパイルにかかる時間」の方が長くなり、結果としてレスポンスが悪化します。
- メモリとCPUの浪費: 複雑なクエリをコンパイルする際、LLVMはかなりのメモリを消費します。高負荷な環境で多数のセッションが同時にJITを要求すると、OSレベルでのメモリ枯渇やコンテキストスイッチの増大を招くリスクがあります。
トラブルシューティング：JITが「敵」に回ったとき
もし、本番環境で「JITを有効にしてから全体的に遅くなった」「CPU負荷が異常に高い」と感じたら、まずは以下のパラメータを疑ってください。
— 現在の設定を確認
SHOW jit;
SHOW jit_above_cost;
SHOW jit_inline_above_cost;
1. `jit_above_cost` の調整
この値は、「どのくらいのコスト見積もりのクエリからJITを適用するか」を決める閾値です。デフォルトの100,000は、小規模なデータベースでは低すぎることがあります。
もし、OLTP系のクエリが誤ってJITコンパイルされているなら、この値を引き上げることで、JITが適用されるクエリを「本当に重い分析処理」だけに絞り込めます。
2. `jit_optimize_above_cost`
LLVMに最適化を行わせるコストの閾値です。最適化（インライン展開など）を強めれば強めるほど、生成されるコードの質は上がりますが、コンパイル時間は指数関数的に増えます。ここをチューニングすることで、「コンパイル時間と実行時間のバランス」を最適化できます。
3. EXPLAIN ANALYZE で見極める
クエリチューニングの基本ですが、`EXPLAIN ANALYZE` を実行すると、JITが実際に使われたかどうかがわかります。
JIT:
Functions: 3
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 1.2ms, Inlining 5.4ms, Optimization 12.1ms, Emission 8.2ms, Total 26.9ms
この「Timing」セクションを見てください。もし、実行時間に対してGenerationやOptimizationの時間が大きな割合を占めているのであれば、それは「JITがオーバーヘッドになっている」証拠です。
エンジニアとしての向き合い方
JITは魔法の杖ではありません。PostgreSQLという堅牢なデータベースの上に、高度な最適化レイヤーを乗せるための「アクセル」です。
私のアドバイスとしては、まずはJITをデフォルトで有効にしたまま、スロークエリログを詳細に監視してください。もし、分析用のクエリがJITによって数倍の速度向上を見せているなら、それは成功です。逆に、日々のトランザクション処理がJITによって遅延しているなら、閾値を上げるか、あるいは特定のセッションだけ無効化する判断も必要です。
結局のところ、データベースのパフォーマンスチューニングに「銀の弾丸」は存在しません。しかし、LLVMが内部で何をしているのか、なぜコンパイルに時間がかかるのかという背景を知っていれば、私たちは「勘」ではなく「設計」に基づいて最適化ができるようになります。
皆さんのクエリが、明日もスムーズに走ることを願っています。それでは。
コメント