パイプラインブレーカとブロッキングオペレータ

パイプラインを分断する演算子とは

クエリの物理プランは演算子の木ですが、実行の観点ではもう一段粗い単位――パイプラインで捉えると、メモリとスケジューリングの挙動が一気に見通せます。パイプラインとは、行が止まらず流れ続ける一連の演算子の区間のことです。Scan が読んだ行が Filter を通り、そのまま結合の探索側を抜け、出力へ――この間どの演算子も「次の1行」を即座に上へ渡せるなら、それは1本のパイプラインです。

この流れを断ち切る演算子をパイプラインブレーカ（pipeline breaker）、あるいは**ブロッキングオペレータ（blocking operator）**と呼びます。定義は明快で、入力を最後の1行まで読み終えるまで、出力の最初の1行を生成できない演算子です。途中まで読んだだけでは答えが確定しないため、行を上へ流せず、そこでパイプラインが分断されます。

-- パイプライン境界の例（Sort がブレーカ）
[ パイプライン2 ]   Sort.next() → ... 上流へ
        ▲ ここで分断（Sort は全入力を読むまで何も返せない）
[ パイプライン1 ]   Scan → Filter → Sort へ全行を投入

なぜ全入力が要るのかは演算子ごとに理由が違いますが、効果は共通です。入力全体（または結合の片側全体）を状態としてメモリに保持する必要が生じ、それがクエリのピークメモリとスケジューリングの両方を支配します。本稿はこの構造を、メモリ確保と実行スケジューリングの観点から掘り下げます。実行モデルそのものの違いはクエリ実行モデルを参照してください。

なぜ「全入力」が必要になるのか

代表的なブロッキングオペレータが、なぜ最後の行まで待つのかを整理します。

• ソート（ORDER BY・マージ結合の前処理）: 最小値が入力のどこに現れるか事前に分からないため、全行を見るまで先頭の出力を確定できない。全行を整列バッファに溜める必要がある。
• ハッシュ集約（GROUP BY・DISTINCT）: あるグループの集計値は、そのキーを持つ最後の行を読むまで確定しない。全グループ分の集約状態をハッシュテーブルに保持する。
• ハッシュ結合の構築側（build）: 探索（probe）を始める前に、片側全体からハッシュテーブルを作り切る必要がある。構築側は完全にブロッキングで、探索側はそのテーブルが完成して初めて流れ出す（ハッシュ結合のGrace/Hybrid）。
• ウィンドウ関数・UNION(重複排除)・一部の集合演算: パーティション全体やソート順が確定しないと値を出せない。

対照的に、**ノンブロッキング（パイプライン可能）**な演算子は、Scan・Filter・式評価・ネステッドループ結合の探索側・ハッシュ結合の探索側など、「1行入れば1行(または0行)出せる」もので、状態をほとんど溜めません。

メモリ確保の主因はブレーカである

ブロッキングオペレータが溜める状態こそが、クエリのピークメモリを決めます。PostgreSQL の work_mem、他システムの作業メモリやソート領域は、この状態を載せるための予算です。重要なのは、この予算が演算子（ノード）単位で確保される点です。

-- 同一クエリ内に複数のブレーカがあると予算は積み上がる
Hash Join
  ├─ Hash (build)        ← work_mem 1 つぶん
  └─ Sort (probe 側入力)  ← work_mem もう 1 つぶん
ピークメモリ ≒ 同時に生存するブレーカ状態の合計

つまりプラン内に複数のブロッキングオペレータがあり、それらの状態が**同時に生存（オーバーラップ）**するなら、消費メモリはおおむねその合計になります。並列実行ではワーカーごとにこの予算が掛かるため、並列度 × ノード数 × work_mem のオーダーで膨らみ得ます。「work_mem を上げたら同時実行でメモリが枯渇した」という典型的事故の根はここにあります。

状態が予算に収まらなければ、ブレーカは中間データを一時ファイルへ書き出す**スピル（spill）**に移行します。スピルした瞬間からそのオペレータは CPU 律速ではなく I/O 律速になり、何回データを読み書きするかが速度を決めます。ソートなら外部ソートの多方向マージ、ハッシュ集約・ハッシュ結合ならパーティション分割と再帰処理に切り替わります（原理は外部ソートとスピルを参照）。

パイプライン境界はスケジューリングの単位

ブレーカがもたらすもう一つの帰結がスケジューリングです。パイプライン境界は、実行エンジンが「ここまでを一気に流す」と決める単位そのものになります。

ブロッキングオペレータの下流（出力側）のパイプラインは、上流（入力側）のパイプラインが完全に終わるまで開始できません。ソートが全行を整列し終えるまで、その上のマージ結合は1行も処理できない。ハッシュ結合の構築が終わるまで、探索側パイプラインは走り出せない。ブレーカは逐次化（直列化）のポイントなのです。

-- 実行の時間軸（→ が時間。P1 が終わってから P2 が動く）
P1: Scan→Filter→Build/Sort  =======■(完了)
P2:                                 ======> （ここで初めて開始）

この性質から、スケジューラの設計上いくつかの帰結が生まれます。

• 並列化の境界: 1本のパイプライン内は素直に並列化（パーティション並列・データ並列）できますが、ブレーカをまたぐと「全ワーカーの上流完了を待ち合わせる」**同期点（バリア）**が入ります。並列の効きは概ねパイプライン単位で、ブレーカが多いほど待ち合わせが増えます。
• メモリ予算の配分: 同時に生きるパイプラインが少ないほど、各ブレーカへ割けるメモリが増えスピルを避けやすい。逆に多数のブレーカが同時生存するプランは、限られた予算を分け合い全員が中途半端にスピルしがちです。実行順をブレーカ境界で区切れることは、メモリ予算をいつ・どこへ振るかを決める足場になります。
• 構築の先行スケジューリング: ハッシュ結合では、探索側の前に構築側を先に走らせ切る必要があります。複数結合が連なるプランで「どの構築を先に作るか」「いくつ同時に構築状態を持つか」は、ピークメモリと直結する設計判断です。

実行計画でブレーカを読む

実行計画上、ブロッキングオペレータは特徴的なノードとして現れます。PostgreSQL の EXPLAIN ANALYZE を例に取ると、見分け方と危険信号は次の通りです。

実行計画を読むときの勘所は、ノードを上から眺めて「最初に行をブロックするのはどこか」を特定することです。そこがパイプラインの分断点であり、メモリ確保とスピルが起きる第一容疑者です。external merge・Batches > 1・Disk Usage のいずれかが出ていれば、そのブレーカで作業メモリを超過しています。対処は二択で、work_mem を増やして in-memory に収めるか、前段で行数を減らして溜める量自体を小さくするか。前者は同時実行でのメモリ枯渇と裏腹なので、まずは行数見積もりの精度（カーディナリティ推定）を疑うのが定石です。

まとめ

• **パイプラインブレーカ（ブロッキングオペレータ）**は、入力を全件読み終えるまで出力を1行も生成できない演算子。ソート・ハッシュ集約・DISTINCT・ハッシュ結合の構築側・ウィンドウ関数などが該当し、実行計画のパイプラインをそこで分断する。
• メモリ面では、ブレーカが入力全体（結合では片側全体）を状態として溜めるため、これがクエリのピークメモリと作業メモリ（work_mem）確保の主因。同時生存するブレーカ状態の合計がピークを決め、並列度・ノード数で掛け算的に膨らむ。予算を超えればスピルし I/O 律速に転じる。
• スケジューリング面では、パイプライン境界が逐次化点となり、下流は上流ブレーカの完了を待つ。これが並列化のバリア、メモリ予算配分の単位、構築の先行スケジューリングの基準になる。
• 実行計画では Sort・Hash・HashAggregate 等がブレーカで、external merge・Batches > 1・Disk Usage がスピルの合図。work_mem 調整と行数見積もりの改善が効く。スピルの内部機構は外部ソートとスピル、実行モデル全体はクエリ実行モデルを参照。