The executor 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.
    To provide a concrete example, assume that the top
    node is a MergeJoin 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
    lefttree). The new top node (the top node of the left
    subplan) is, let's say, a
    Sort node and again recursion is needed to obtain
    an input row.  The child node of the Sort might
    be a SeqScan 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 Sort
    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 Sort 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.
   
    The MergeJoin 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 MergeJoin node returns NULL to indicate that
    no more join rows can be formed.
   
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 four basic SQL query
    types: SELECT, INSERT,
    UPDATE, and DELETE.
    For SELECT, the top-level executor code
    only needs to send each row returned by the query plan tree
    off to the client.  INSERT ... SELECT,
    UPDATE, and DELETE
    are effectively SELECTs under a special
    top-level plan node called ModifyTable.
   
    INSERT ... SELECT feeds the rows up
    to ModifyTable for insertion.  For
    UPDATE, the planner arranges that each
    computed row includes all the updated column values, plus the
    TID (tuple ID, or row ID) of the original
    target row; this data is fed up to the ModifyTable
    node, which uses the information to create a new updated row and
    mark the old row deleted.  For DELETE, the only
    column that is actually returned by the plan is the TID, and the
    ModifyTable node simply uses the TID to visit each
    target row and mark it deleted.
   
    A simple INSERT ... VALUES command creates a
    trivial plan tree consisting of a single Result
    node, which computes just one result row, feeding that up
    to ModifyTable to perform the insertion.