# クエリ実行プラン ## 定義 クエリ実行プラン(Query Execution Plan)とは、SQLクエリテキストを変換して得られる、木構造(まれにDAG構造)のデータフローネットワークである。ノードは物理演算子(TABLE_SCAN・PROJECTION・FILTER・HASH_GROUP_BY・HASH_JOIN等)であり、各ノードは1つの計算ステップを実装する。エッジは子演算子から親演算子へ向かい行データを運ぶ。[[DuckDB]]ではエッジ上を2048行単位の「データチャンク」が一括して流れ、根の演算子(QUERY)が返す行がクエリ結果を表す(Source: [[@2026__DiDi__Query Execution Plans and Pipelining]])。相関サブクエリや共通テーブル式(CTE)のような特定のSQL機能は、木構造では表現できずDAG形状のプランを要求する。 ## 横断的知見 - **DDIAが教科書レベルで示す「query compilation 対 vectorized processing」という二分法は、DuckDBの2048行データチャンクによるプッシュ型パイプライン実行を後者(vectorized processing)の具体的実装例として位置づける**: DDIA第4章は分析クエリの高速化手法として、SQLを機械語へJITコンパイルし行単位に処理する query compilation(JVM等のJIT方式に類似)と、列のバッチをあらかじめ用意された固定演算子群へ渡す vectorized processing を対比する。既存知見(DuckDBの物理演算子木構造)は演算子間を2048行単位の「データチャンク」が流れると説明しており、これはDDIAが言うvectorized processingの「列のバッチを固定演算子へ渡す」という定義に正確に合致する。DuckDBはコード生成でなくバッチ処理による解釈実行を選ぶ点で、DDIAの二分法における一方の系統(vectorized processing)を選択した具体例として明確に分類できる——既存知見にはこの分類軸(compilation vs vectorization)が欠けていた。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 4 Storage and Retrieval]] "Query Execution: Compilation and Vectorization", [[@2026__DiDi__Query Execution Plans and Pipelining]]) - **両ソースが挙げるCPU効率化の原理(逐次メモリアクセス・タイトな内部ループ・SIMD・圧縮データへの直接操作)は、DuckDBのデータチャンクという具体的なバッチサイズ実装の背後にある一般原理として対応する**: DDIA第4章はvectorized processingが高速化する理由として、逐次メモリアクセスによるキャッシュミス削減・分岐予測ミスを避けるタイトな内部ループ・SIMD命令・圧縮データへの直接操作の4点を挙げる。DuckDBが演算子間で2048行という固定サイズのチャンクを流す設計は、この4原理のうち特にキャッシュ効率(チャンクがCPUキャッシュに収まるサイズ)とSIMD活用(バッチ単位のベクトル演算)を具体的な数値へ落とし込んだものと解釈できる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 4 Storage and Retrieval]] "Query Execution: Compilation and Vectorization", [[@2026__DiDi__Query Execution Plans and Pipelining]]) - **Petrov が示す『ローカル実行とリモート実行を統括する実行エンジン』という分散前提の定義は、DuckDB の単一プロセス内物理演算子木には現れない軸である**: [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]] は、実行エンジンが実行計画を処理する際に「ローカル操作とリモート操作の実行結果を収集する」と説明し、リモート実行にはクラスタ内の他ノードでのデータ読み書き・レプリケーションが含まれるとする。これは分散 DBMS を前提とした一般的な実行エンジンの定義である。一方、[[@2026__DiDi__Query Execution Plans and Pipelining]] が説明する DuckDB の物理演算子木は単一プロセス内のデータチャンク流れであり、リモート実行に相当するノードは存在しない。同じ『クエリ実行プラン』という語が、分散システム文脈(ノード間通信を含む)と単一ノード組み込みエンジン文脈(プロセス内データフローのみ)で異なる範囲を指すことが、書籍と講義シリーズという独立した2ソースの対比で明確になった。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]], [[@2026__DiDi__Query Execution Plans and Pipelining]]) ## 未解決の問い - クエリオプティマイザ(論理プランから物理プランへの変換、コストベース最適化)は本概念とどう接続するか。DiDi講義シリーズの他回(オプティマイザ回)が取り込まれ次第、対応関係を追記する。 - DAG形状プランを生む相関サブクエリ・CTEの具体的な実行プラン例(演算子構成)はどうなるか。 - DuckDBの2048行チャンクサイズは、DDIAが一般原理として挙げる4要素(キャッシュ効率・分岐予測・SIMD・圧縮データ直接操作)のどれを最も強く反映して選ばれた値か。チャンクサイズを変えた場合の性能感度は文献から読み取れるか。 - query compilation方式(JITコンパイル)を採用するDBMS(例: Umbra, HyPer)の実行プランは、DuckDBのvectorized処理の物理演算子木構造とどこまで同じ表現(木構造・データチャンク流)で記述できるか、それとも根本的に異なるプラン表現を要するか。 - 分散 DBMS のリモート実行(ノード間のデータ読み書き・レプリケーション)は、単一ノード組み込みエンジンの物理演算子木構造と同じ木/DAG表現で記述できるか、それとも別種の抽象(たとえばフラグメント間通信を表すノード種別)が必要か。本 wiki には分散クエリ実行プランを詳説するソースがまだない。 ## 関連 - ソース: [[@2026__DiDi__Query Execution Plans and Pipelining]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 4 Storage and Retrieval]] / [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]] - 概念: [[プッシュ型パイプライン実行]] - エンティティ: [[DuckDB]] / [[Torsten Grust]] / [[Universität Tübingen]] ## 出典 - [[@2026__DiDi__Query Execution Plans and Pipelining]](DuckDBの物理演算子木構造プランを解説する一次ソース) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 4 Storage and Retrieval]](§Query Execution: Compilation and Vectorization — query compilationとvectorized processingの教科書的分類とCPU効率化原理) - [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]](§1.1 — 分散前提の実行エンジン。ローカル/リモート実行の統括)