PostgreSQLの並列クエリ、その「甘い罠」と最適化の深淵
PostgreSQLの並列クエリ（Parallel Query）は、導入当初こそ「魔法の杖」のように見えました。しかし、本番環境のクリティカルなパスで利用するようになると、多くのエンジニアが一度は「あれ、なんで期待したほど速くならないんだ？」という壁に突き当たります。
今日は、ドキュメントのパラメータ説明をなぞるのではなく、PostgreSQLの内部アーキテクチャに深く切り込み、なぜデフォルト設定が「安全だが非効率」なのか、そして真のチューニングとは何かについて語りたいと思います。
—
並列度の決定プロセス：オプティマイザの「慎重すぎる」判断
まず、クエリが並列化されるためには、プランナが「コスト」を計算し、その結果が一定の閾値を超える必要があります。ここで、皆さんがよく手にするであろうパラメータが関わってきます。
- `min_parallel_table_scan_size`: ここが並列化の最初のハードルです。
- `min_parallel_index_scan_size`: インデックススキャンにおける閾値です。
多くのエンジニアは、これらを「もっと速くしたいから」といって闇雲に小さくします。しかし、これは危険な博打です。
並列クエリのオーバーヘッドは、プロセス間通信（IPC）と、リーダープロセスによるバックグラウンドワーカーの立ち上げに起因します。小さなテーブルに対して並列化を強行すれば、純粋な処理時間よりも「ワーカーの起動・終了とコンテキストスイッチ」のコストが上回ってしまう。「小さすぎるテーブルを無理に並列化する」ことこそ、並列クエリの最大の敵です。
max_parallel_workers_per_gather が支配する実効性能
`max_parallel_workers_per_gather` は、1つのGatherノードが生成できるワーカー数の上限を定義します。しかし、ここで混同してはいけないのが、`max_parallel_workers`（システム全体）と `max_worker_processes`（OSのリソース制限）との関係です。
よくあるトラブルシューティングの現場では、この値が「物理コア数」とイコールで結ばれていますが、現実はもっと複雑です。
- I/Oのボトルネック: ディスクがストレージの帯域幅を使い切っている場合、いくらワーカーを増やしても、待機時間が伸びるだけです。
- CPUコンテンション: 既に高負荷なOLTPクエリが走っている状況で、さらに重い並列クエリを投げ込めば、CPUキャッシュの奪い合いが始まり、全体のスループットがガタ落ちします。
私の経験上、この値は「物理コア数」ではなく、「他のバックグラウンドタスクや定期バッチが走っていない時の、CPUの余剰分」を基準に決めるべきです。
なぜ「コストパラメータ」が全てを左右するのか
どれだけ `max_parallel_workers_per_gather` を調整しても、プランナが並列プランを選んでくれなければ意味がありません。ここで鍵となるのが、以下のコストパラメータです。
- `parallel_tuple_cost`: ワーカー間のデータ転送コスト。
- `parallel_setup_cost`: ワーカーの起動コスト。
デフォルト値は非常に保守的です。もし皆さんの環境が高速なNVMe SSDと多コアCPUを積んでいるなら、これらのコスト係数を下げてやることで、プランナは「並列化をより積極的に採用」するようになります。
逆に、`random_page_cost` を下げすぎている環境では、プランナが「並列インデックススキャン」を過信し、かえってランダムI/Oを増幅させるという本末転倒な事態も起こり得ます。チューニングは常に、ストレージの特性とセットで考えるべきなのです。
現場で役立つチューニングの心得
最後に、トラブルシューティングの際の私の手順をシェアします。
1. `EXPLAIN (ANALYZE, VERBOSE)` で確認する:
プランが並列化されているか？ それとも、コスト見積もりが外れて「並列化すべきところでシーケンシャルスキャン」になっているか？ もし見積もりが外れているなら、それは統計情報（`ANALYZE`）の鮮度が落ちているサインです。
2. `pg_stat_activity` を監視する:
ワーカープロセスが `wait_event` で何に詰まっているかを確認してください。`DataFileRead` ならI/O、`LWLock` ならバッファ管理やIPCの競合です。
3. 「並列化しない」勇気を持つ:
どんなに調整しても、特定のクエリは並列化しない方が速い場合があります。その時は、`SET LOCAL max_parallel_workers_per_gather = 0;` を使って、特定のクエリだけ並列化を無効化するのも、熟練したエンジニアの戦略の一つです。
—
並列クエリは、PostgreSQLの強力な武器ですが、同時に諸刃の剣でもあります。教科書的な設定を鵜呑みにせず、自分の環境のI/OプロファイルとCPU負荷を深く理解すること。そこから本当の最適化が始まります。
皆さんのクエリが、今日も効率的に、そして美しく実行されることを願っています。
コメント