The <firstterm>executor</firstterm> takes the plan created by the planner/optimizer and recursively processes it to extract the required set of rows. This is essentially a demand-pull pipeline mechanism. Each time a plan node is called, it must deliver one more row, or report that it is done delivering rows. エグゼキュータは、プランナ/オプティマイザで作成された計画を受け取り、必要な行の集合を抽出するために再帰的に処理します。 これは本質的に要求引き寄せ型（demand-pull）パイプライン機能です。 計画ノードが呼ばれる度にもう1つの行を引き渡すか、行を引き渡したことの報告を行わなければなりません。

To provide a concrete example, assume that the top node is a <literal>MergeJoin</literal> node. Before any merge can be done two rows have to be fetched (one from each subplan). So the executor recursively calls itself to process the subplans (it starts with the subplan attached to <literal>lefttree</literal>). The new top node (the top node of the left subplan) is, let's say, a <literal>Sort</literal> node and again recursion is needed to obtain an input row. The child node of the <literal>Sort</literal> might be a <literal>SeqScan</literal> node, representing actual reading of a table. Execution of this node causes the executor to fetch a row from the table and return it up to the calling node. The <literal>Sort</literal> node will repeatedly call its child to obtain all the rows to be sorted. When the input is exhausted (as indicated by the child node returning a NULL instead of a row), the <literal>Sort</literal> code performs the sort, and finally is able to return its first output row, namely the first one in sorted order. It keeps the remaining rows stored so that it can deliver them in sorted order in response to later demands. 具体的な例を提供する目的で頂点のノードがMergeJoinノードである場合を想定しましょう。 いかなるマージも実行される前に（それぞれの副計画から1つずつ）2つの行を取ってこなくてはいけません。 ですからエグゼキュータは副計画を処理するために自分自身を再帰的に呼び出します（lefttreeに付随する副計画から開始します）。 新しい頂点のノード（左の副計画の頂点のノード）はSortノードであるとしましょう。ここでもノード自体が処理される前に入力行を取ってこなくてはいけません。 Sortの子ノードは実際のテーブルの読み取りを表現しているSeqScanノードのこともあり得ます。 このノードの処理はエグゼキュータにテーブルから行を抽出させ、呼び出しているノードに渡し戻させます。 Sortノードはソート対象の全てのノードを取得するために子ノードを繰り返し呼び出します。 入力がなくなった時（子ノードが行ではなくNULLを返してきた時）Sortコードがソートを実行して最終的に最初の出力行を返すことができるようになります。 つまりソート順における最初の結果です。 後での要求に答えるためソート順に引き渡すことができるように残っている行は保存されます。

The <literal>MergeJoin</literal> node similarly demands the first row from its right subplan. Then it compares the two rows to see if they can be joined; if so, it returns a join row to its caller. On the next call, or immediately if it cannot join the current pair of inputs, it advances to the next row of one table or the other (depending on how the comparison came out), and again checks for a match. Eventually, one subplan or the other is exhausted, and the <literal>MergeJoin</literal> node returns NULL to indicate that no more join rows can be formed. MergeJoinノードは同じようにしてその右副計画から最初の行を要求します。 そこで2つの行が結合できるかどうか比較されます。もし結合できる場合には呼び出し側に結合された行が返されます。 次の呼び出しの時に、もしくは入力された現在の組み合わせが結合できない場合はすぐに、あるテーブルあるいはそれ以外のテーブル（比較の結果に依存して）の次の行に進んで、さらに一致があるかどうか検証されます。 最終的にはある副計画もしくは他の計画が使いきられ、MergeJoinノードがこれ以上の結合行を生成できないという意味のNULLを返すことになります。

Complex queries can involve many levels of plan nodes, but the general approach is the same: each node computes and returns its next output row each time it is called. Each node is also responsible for applying any selection or projection expressions that were assigned to it by the planner. 複雑な問い合わせは多くの階層となった計画ノードに関わるかもしれませんが、概略的な取り扱い方は同じです。 それぞれのノードは呼び出される度に次の出力行を計算して返します。 それぞれのノードは同時にプランナによって割り当てられたいかなる選択式や射影式でも適用する責任があります。

The executor mechanism is used to evaluate all five basic SQL query types: <command>SELECT</command>, <command>INSERT</command>, <command>UPDATE</command>, <command>DELETE</command>, and <command>MERGE</command>. For <command>SELECT</command>, the top-level executor code only needs to send each row returned by the query plan tree off to the client. <command>INSERT ... SELECT</command>, <command>UPDATE</command>, <command>DELETE</command>, and <command>MERGE</command> are effectively <command>SELECT</command>s under a special top-level plan node called <literal>ModifyTable</literal>. エグゼキュータ機構は5つの基本的なSQL問い合わせの種類すべてを検証するために用いられます。 5つのSQL問い合わせの種類とはSELECT、INSERT、UPDATE、DELETE、そしてMERGEです。 SELECTでは、最上位階層のエグゼキュータコードは問い合わせ計画ツリーによって返されるそれぞれの行をクライアントへ送り返すだけでよいことになっています。 INSERT ... SELECT、UPDATE、DELETE、MERGEは、実質的にはModifyTableと呼ばれる特別な最上位階層の計画ノードの下のSELECTです。

<command>INSERT ... SELECT</command> feeds the rows up to <literal>ModifyTable</literal> for insertion. For <command>UPDATE</command>, the planner arranges that each computed row includes all the updated column values, plus the <firstterm>TID</firstterm> (tuple ID, or row ID) of the original target row; this data is fed up to the <literal>ModifyTable</literal> node, which uses the information to create a new updated row and mark the old row deleted. For <command>DELETE</command>, the only column that is actually returned by the plan is the TID, and the <literal>ModifyTable</literal> node simply uses the TID to visit each target row and mark it deleted. For <command>MERGE</command>, the planner joins the source and target relations, and includes all column values required by any of the <literal>WHEN</literal> clauses, plus the TID of the target row; this data is fed up to the <literal>ModifyTable</literal> node, which uses the information to work out which <literal>WHEN</literal> clause to execute, and then inserts, updates or deletes the target row, as required. INSERT ... SELECTは挿入のためにModifyTableに行を入力します。 UPDATEでは、プランナはすべての更新された列の値を含んだ行の演算結果と元の対象行のTID（タプルID、または行ID）を準備します。 このデータはModifyTableノードに入力され、ノードでは新しく更新された行の作成と古い行に削除の印を付けるためにこの情報を利用します。 DELETEでは、計画から実際に返されるただ1つの列はTIDで、ModifyTableノードは単に各対象行を尋ね当てて削除の印を付けるためにこのTIDを使用します。 MERGEでは、プランナは元のリレーションと対象のリレーションを結合し、WHEN句のいずれかで必要とされるすべての列の値と対象行のTIDを含みます。 このデータはModifyTableノードに入力され、実行までのWHEN句を判断し、必要に応じて対象行を挿入、更新、または削除するためにこの情報を利用します。

A simple <command>INSERT ... VALUES</command> command creates a trivial plan tree consisting of a single <literal>Result</literal> node, which computes just one result row, feeding that up to <literal>ModifyTable</literal> to perform the insertion. 単純なINSERT ... VALUESコマンドは、1つのResultノードからなる単純な計画ツリーを生成し、そのノードは結果としての行を1つだけ計算し、挿入を実行するためにその行がModifyTableに入力されます。