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

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

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

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

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