PostgreSQLの「影の働き手」：パラレルワーカーの内部構造と現場のリアル
PostgreSQLのパラレルクエリ。これに初めて遭遇した時の「クエリプランナーが勝手に並列化して処理時間を劇的に短縮した」という感動は、今でも忘れられません。しかし、データベースの深淵を覗き込むエンジニアなら誰しもが思うはずです。「一体、裏側で何が起きているのか？」と。
今回は、我々が愛してやまないPostgreSQLの「パラレルワーカー」に焦点を当てます。教科書的な定義を超えて、このプロセスたちがどのように協調し、そして時として我々を悩ませるのか。そのアーキテクチャの真髄を紐解いていきましょう。
1. パラレルワーカーの正体：ただの「分身」ではない
パラレルワーカーは、リーダープロセス（ユーザーが直接接続しているバックエンドプロセス）から `LaunchParallelWorkers` 関数を通じてフォークされる、いわば「使い捨ての精鋭部隊」です。
彼らの最大の特徴は、「共有メモリ空間（Shared Memory）」への依存にあります。
- 動的バックグラウンドワーカー: パラレルワーカーは動的に生成されます。彼らは `ParallelContext` を介してリーダーとメモリを共有し、`dsm` (Dynamic Shared Memory) を使って計算結果や状態を同期させます。
- 孤立と統合: 各ワーカーは独立したプロセスでありながら、リーダーと `ParallelState` を共有しています。彼らが計算した中間結果（例えば、ハッシュ結合のハッシュテーブルの構築の一部など）は、共有メモリを通じてリーダーへ集約される仕組みです。
2. 内部で起きていること：同期のダンス
パラレルワーカーが起動されるとき、そこには非常に緻密な制御が存在します。
最も重要なのが `ParallelWorkerContext` による同期です。ワーカーは、リーダーから割り当てられたプランツリーの一部を実行します。ここで注目すべきは、ワーカーが「どこまで処理したか」を管理する `ParallelExecutorState` です。
例えば、`Parallel Seq Scan` を想像してください。リーダーとワーカーたちは、共有メモリ上の「ページ範囲」をアトミックにロックしながら確保し、互いに重複しないようにテーブルをスキャンしていきます。この「誰がどの行を読んだか」を制御するロックの競合こそが、パラレルクエリのパフォーマンスを左右する最大のボトルネックになるのです。
3. なぜ「思ったより速くならない」のか？（トラブルシューティングの勘所）
パラレルクエリを導入して「期待した性能が出ない」と嘆く現場に何度も遭遇しました。その原因の多くは、以下の3点に集約されます。
① ワーカーの起動オーバーヘッド
短時間のクエリに対してパラレル化を強制するのは、実は逆効果です。ワーカーのフォーク（`fork()`）とメモリの初期化には相応のコストがかかります。`min_parallel_table_scan_size` の設定が適切か、自身のワークロードに合わせてチューニングしているでしょうか？
② 共有メモリの競合 (LWLock)
ワーカーが多すぎると、`Parallel Seq Scan` におけるページスキャン時のロック競合（`LWLock`）が激増します。CPUコア数に合わせて闇雲に `max_parallel_workers_per_gather` を上げるのは禁物です。`pg_stat_activity` を覗き、ワーカーがどのような待機イベント（Wait Event）で止まっているかを冷静に観察してください。
③ データスキューと不均衡な負荷
ワーカーたちが同じ計算量になる保証はありません。データが偏っている場合、1つのワーカーだけが重い処理を抱え、他のワーカーが終了を待つ「ロングテール現象」が発生します。実行計画（`EXPLAIN (ANALYZE, VERBOSE)`）を見て、各ワーカーの `loops` や `actual time` に大きな乖離がないかを確認してください。
4. 最後に：エンジニアとしての向き合い方
パラレルワーカーは魔法ではありません。彼らは、PostgreSQLの洗練された共有メモリ管理とプロセス間通信の上に成り立つ、極めて論理的な仕組みです。
トラブルに直面したとき、まずは `pg_stat_bgwriter` や `pg_stat_activity` を確認し、「彼らが何で待たされているのか」を特定してください。そして、プランナがなぜその並列度を選んだのか、`COST` の概念に立ち返ってみる。
結局のところ、データベースエンジニアリングの面白さは、こうした目に見えないプロセスの「呼吸」を感じ取れるようになることにあるのだと、私は確信しています。
皆さんのPostgreSQLが、今日も軽快にクエリを捌いていることを願って。それでは、また。
コメント