PostgreSQLの「並列クエリ」を使いこなす：マルチコアを味方にするための深淵なる知見
PostgreSQLの並列クエリ（Parallel Query）について、皆さんはどれほど「直感的」に理解できていますか？
「とりあえず `max_parallel_workers_per_gather` を増やせば速くなる」といったレベルの話は、もう卒業しましょう。実戦の現場では、不用意な並列化は劇薬にもなり得ます。今日は、PostgreSQLの並列クエリがどのような内部構造で動き、なぜ時にパフォーマンスを劇的に向上させ、また時にシステム全体を窒息させるのか。その「呼吸」を紐解いていきます。
—
並列クエリのアーキテクチャ：LeaderとWorkerの協調作業
PostgreSQLの並列クエリは、単に「マルチスレッドで動く」という単純な話ではありません。プロセスベースのアーキテクチャであるPostgreSQLにおいて、これは「Leaderプロセス」と複数の「Parallel Workerプロセス」による協調作業を意味します。
1. プランニングの段階: オプティマイザが `Gather` や `Gather Merge` ノードを含む計画を作成します。ここで重要なのは、コストモデルに基づいた「並列化する価値があるか」の厳格な判断です。
2. Workerの起動: 実行時、Leaderプロセスは `Parallel Worker` を起動します。この際、共有メモリ（Dynamic Shared Memory）を介して、実行計画のツリーや、現在のクエリの状態を同期させます。
3. タスクの分割: ここが肝です。スキャン（Sequential Scan）であれば、データページをプロセス間で「チャンク」として分割し、それぞれが独立して読み込みます。
この仕組みにおいて最もコストがかかるのは、プロセスの起動オーバーヘッドと、プロセス間通信（IPC）による同期です。特に、短時間で終わるクエリで無理に並列化を行うと、CPUの恩恵よりもコンテキストスイッチのコストが上回り、かえって遅くなるという悲劇が起こります。
—
トラブルシューティング：なぜ「並列化」が裏目に出るのか
並列クエリのチューニングで一番多い失敗は、「並列化が効きすぎて、I/OやCPUを飽和させる」ことではなく、「期待した並列度が出ない」、あるいは「並列化がかえってボトルネックになる」というケースです。
もし `EXPLAIN ANALYZE` を見て、意図した並列数が動いていないなら、まずは以下の3点を疑ってください。
- `max_parallel_workers_per_gather` だけを見ていないか？
実は `max_worker_processes` や `max_parallel_workers` という「全体の上限」に引っかかっているケースが非常に多いです。これらはシステム全体のリソース設計に関わるため、個別のチューニングだけで解決しようとすると泥沼化します。
- データスキュー（偏り）の罠
並列クエリはチャンク単位で処理を割り振りますが、特定のWorkerだけが重いデータページを掴んでしまい、他のWorkerが待機状態になるケースがあります。特にインデックスが効かない結合でこの現象が起きると、全体の実行時間は「最も遅いWorker」に引きずられます。
- 共有バッファの競合
並列クエリは大量のバッファを同時に読み込みます。共有バッファ（`shared_buffers`）のサイズが不十分だと、プロセス間でバッファの争奪戦が起き、ロック競合（`LWLock`）で性能が頭打ちになります。
—
「真のエンジニア」のための定石：並列化の判断基準
私の経験上、並列クエリを適用すべきは「巨大なテーブルの全走査」や「複雑な結合を含む分析クエリ」に限定すべきです。
逆に、OLTP系の高頻度なクエリに並列化を適用するのは、多くの場合「悪手」です。 理由の筆頭は、接続数が増大した際に、並列プロセスの乱立でメモリ消費が爆発し、OOM Killerに殺されるリスクがあるからです。
もしあなたが大規模なデータ分析基盤を構築しているなら、以下の指針を意識してみてください。
- `min_parallel_table_scan_size` の調整: 小さなテーブルまで並列化しないよう、閾値を適切に設定する。
- クエリごとの並列度指定: `ALTER TABLE … SET (parallel_workers = N)` で、テーブルごとの特性に応じた並列度を定義しておく。
- 統計情報の鮮度: オプティマイザは統計情報を信じます。`ANALYZE` が適切に行われていないと、並列化すべきところで並列化されず、その逆もまた然りです。
—
最後に
並列クエリは、PostgreSQLという堅牢なエンジンに与えられた強力な「ブースト」です。しかし、使いこなすにはエンジン内部の挙動を想像する力が必要です。「なぜこのクエリは並列化されたのか？」「なぜこのノードで時間がかかっているのか？」。`EXPLAIN (ANALYZE, BUFFERS, VERBOSE)` の出力結果を読み解く際、単なる数字の羅列ではなく、プロセスたちがどう連携し、どこで肩をすくめているのか、そのドラマを想像してみてください。
技術は、仕様を知るだけではなく、その背景にあるアーキテクチャの哲学に寄り添うことで、初めて自分の指先のように扱えるようになります。
皆さんのデータベースが、今日も健やかに、そして軽快に動いていることを願っています。
コメント