エクゼキュータは、プランナ/オプティマイザから返された計画を受け取り、必要な行の集合を抽出する処理を反復します。 これは本質的に要求引き寄せ型（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で指定された対象となるテーブルに返された行が挿入されます （ある単純なINSERT ... VALUES命令は1つのResultを所有している単純な計画ツリーを生成し、結果としての行を1つだけ計算するに留まります。 しかし、INSERT ... SELECTはエクゼキュータ機構ができ得る限りの能力を発揮することを必要とする場合があります）。 UPDATEではプランナは全ての更新された列の値を含んだ行の演算結果とTID（タプルID、または行ID）を準備します。 エクゼキュータの最上階層レベルでは新しく更新された行の作成と削除された古い行に印を付けるためこの情報を利用します。 DELETEでは計画から実際に返されたただ1つの列はTIDで、エクゼキュータの最上階層レベルは各対象行を尋ね当てることと削除の印を付けるために単にこのTIDを使用します。