他のバージョンの文書 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

40.6. エクゼキュータ

エクゼキュータは、プランナ/オプティマイザから返された計画を受け取り、必要な行の集合を抽出する処理を反復します。 これは本質的に要求引き寄せ型(demand-pull)パイプライン機能です。 計画ノードが呼ばれる度にもうひとつの行を引き渡すか、行を引き渡したことの報告を行わなければなりません。

具体的な例を提供する目的で頂点のノードが MergeJoin ノードである場合を想定しましょう。 いかなるマージも実行される前に(それぞれの副計画から 1 つづつ) 2 つの行を取って来なくてはいけません。 ですからエクゼキュータは副計画を処理するために自分自身を再帰的に呼び出します(lefttree に付随する副計画から開始します)。 新しい頂点のノード(左の副計画の頂点のノード)は Sort ノードで、ここでもノード自体が処理される前に入力行を取って来なくてはいけません。 Sort の子ノードは実際に読み込む対象のテーブルを表現している SeqScan ノードのこともあり得ます。 このノードの処理はエクゼキュータにテーブルから行を抽出させ呼び出しているノードに渡し戻させます。 Sort ノードはソート対象の全てのノードを取得するために子ノードを反復呼び出しします。 入力がなくなった時(子ノードが行ではなく NULL を返してきた時)Sort コードがソートを実行して最終的に最初の出力行を返すことができるようになります。 つまりソート順における最初の結果です。 後での要求に応えるためソート順に引き渡すことができるように残っている行は保存されます。

MergeJoin ノードは同じようにしてその右副計画から最初の行を要求します。 そこでふたつの行が結合できるかどうか比較されます。もし結合できる場合には呼び出し側に結合された行が返されます。 次の呼び出しの時に、もしくは入力された現在の組合せが結合できない場合は即刻に、あるテーブルあるいはそれ以外のテーブル(比較の結果に依存して)の次の行に進んで、更に一致があるかどうか検証されます。 最終的にはある副計画もしくは他の計画が使いきられ、MergeJoin ノードがこれ以上の結合行を生成できないという意味の NULL を返すことになります。

複雑な問い合わせは多くの階層となった計画ノードに係わることがありますが、概略的な取り扱い方は同じです。 それぞれのノードは呼び出される度に次の出力行を計算して返します。 それぞれのノードは同時にプランナによって割り当てられたいかなる選択式や射影式でも適用しなければならない責任があります。

エクゼキュータ機構は全ての 4 つの基本的な SQL 型を検証するするために用いられます。 4 つの SQL 型とは SELECTINSERTUPDATE そして DELETE です。 SELECTでは、最上位階層のエクゼキュタコードはクライアントから離れて問い合わせ計画によって返されるそれぞれのだけを行を送り返せば良いことになっています。 INSERTでは、 INSERT で指定された対象となるテーブルに返された行が挿入されます。 (ある単純な INSERT ... VALUES 命令はひとつの Result を所有している単純な計画ツリーを生成し、結果としての行を一つだけ計算するにとどまります。 しかし INSERT ... SELECT はエキュゼキュタ機構ができうる限りの能力を発揮することを必要とする場合があります。 UPDATE ではプランナは全ての更新された列の値を含んだ行の演算結果と TID(タプル ID、または 行 ID)を準備します。 エクゼキュータの最上階層レベルでは新しく更新された行の作成と削除された古い行に印を付けるためこの情報を利用します。 DELETE では計画から実際に返されたただ一つの列は TID で、エクゼキュータの最上階層レベルは各対象行を尋ねあてることと削除の印を付けるために単にこの TID を使用します。