PostgreSQLのパラレルクエリ：その「静かなる革命」とアーキテクチャの深淵
PostgreSQLのパラレルクエリについて語るとき、多くのエンジニアは単に「CPUコアを並列で使う魔法」だと捉えがちです。しかし、この機能がPostgreSQLのアーキテクチャに導入された際、それは単なる機能追加以上の意味を持っていました。いわば、プロセスベースのアーキテクチャという「制約」とどう戦うか、というPostgreSQL開発陣の執念の歴史そのものなんです。
今日は、この「パラレルクエリ」が裏側でどう動き、我々データベースエンジニアがどこに目を光らせるべきか、少し深掘りしてみましょう。
—
プロセスモデルの呪縛と「Dynamic Background Workers」
PostgreSQLは伝統的に「1コネクション＝1プロセス」というモデルを採用しています。これこそが安定性の源泉ですが、並列処理においては最大のボトルネックになります。なぜなら、親プロセス（リーダー）がどうやって他のプロセスを制御し、結果を回収するかという「オーケストレーション」が非常に重い課題だからです。
ここで登場するのが `Background Worker` です。パラレルクエリを実行する際、リーダープロセスは `Parallel Worker` を動的に生成し、共有メモリ（`dsm` – Dynamic Shared Memory）を介してタスクを分配します。
ここで重要なのは、「クエリの並列化は、単にデータを分割するだけではない」という点です。プランナはコスト計算を行い、「並列化したほうが速い」と判断した場合、`Gather` ノードをプランツリーに挿入します。この `Gather` こそが、各ワーカーから送られてくるタスクの断片をまとめ上げ、最終的な結果をクライアントに返すための「交通整理役」なのです。
—
パラレルクエリの深淵：気をつけるべき「罠」
パラレルクエリが有効な場面では劇的なパフォーマンス向上を見せますが、逆に「なぜ遅い？」という状況に陥ることも少なくありません。トラブルシューティングの現場でよく見る、いくつかの落とし穴を挙げておきます。
1. 共有メモリの枯渇
パラレルクエリは、ワーカー間でのデータ受け渡しに共有メモリを多用します。もし、同時実行数が多い環境で `max_parallel_workers` や `max_worker_processes` を安易に引き上げると、メモリ枯渇やプロセス生成のオーバーヘッドがクエリの実行時間を相殺してしまいます。
2. 「Gather」のオーバーヘッド
プランツリーの末端で並列化されても、最後に `Gather` ノードで一本に集約する際に、そのノードがボトルネックになるケースがあります。特に、集計処理（Aggregation）が重い場合、ワーカー側の並列実行が終わっても、リーダー側でメモリに乗り切らないソートが発生し、ディスクI/Oに落ちていく…というシナリオはよくある「あるある」です。
3. 統計情報の嘘
これはパラレルクエリに限った話ではありませんが、プランナが「並列化したほうが速い」と判断する根拠は `pg_statistic` です。テーブルの統計情報が古いと、行数を大幅に見誤り、本来並列化すべきでないクエリを並列化してリソースを食いつぶしたり、あるいはその逆が起こります。
—
トラブルシューティングの勘所
もし本番環境でパラレルクエリが期待通りに動いていないと感じたら、まず `EXPLAIN (ANALYZE, VERBOSE)` を見てください。
- `Workers Planned` と `Workers Launched` が一致しているか？
もし `Launched` が 0 なら、リソース制限や設定値（`min_parallel_table_scan_size` など）によって実行が見送られています。
- ワーカーごとの実行時間の偏り
各ワーカーの実行時間が大きく異なる場合、データの偏り（スキュー）が疑われます。特定のワーカーだけが重い処理を掴まされている状態です。この場合、インデックス設計の見直しや、パーティショニングによるデータの局所化が根本的な解決策になります。
—
最後に：エンジニアとしてどう付き合うか
パラレルクエリは、PostgreSQLが「ビッグデータ」や「複雑な分析」という現代的な課題にどう対応してきたかの回答です。しかし、魔法の杖ではありません。
我々エンジニアがすべきことは、パラレルクエリを「オンにして放置」することではなく、「クエリがどう分割され、どこで合流し、どのリソースがボトルネックになっているか」を想像する視点を持つことです。
プロセスの壁を越え、メモリの海を渡り、最後には一本のストリームとして結果を返す。この美しいダンスを脳内で再現できるようになれば、あなたはもうPostgreSQLのアーキテクチャの深層に到達していると言っても過言ではありません。
皆さんのデータベースに、今日もしなやかな並列処理の恩恵がありますように。
コメント