Robert Haas wrote:
> Can you at least take a stab at it? We can fix your grammar, but
> guessing what's going on without documentation is hard.
With some help from David Fetter, I took another try at it. I hope
someone finds this helpful. I'm happy to answer any questions.
Regards,
Marko Tiikkaja
*** a/src/backend/executor/README
--- b/src/backend/executor/README
***************
*** 25,38 **** There is a moderately intelligent scheme to avoid rescanning nodes
unnecessarily (for example, Sort does not rescan its input if no parameters
of the input have changed, since it can just reread its stored sorted data).
! The plan tree concept implements SELECT directly: it is only necessary to
! deliver the top-level result tuples to the client, or insert them into
! another table in the case of INSERT ... SELECT. (INSERT ... VALUES is
! handled similarly, but the plan tree is just a Result node with no source
! tables.) For UPDATE, the plan tree selects the tuples that need to be
! updated (WHERE condition) and delivers a new calculated tuple value for each
! such tuple, plus a "junk" (hidden) tuple CTID identifying the target tuple.
! The executor's top level then uses this information to update the correct
tuple. DELETE is similar to UPDATE except that only a CTID need be
delivered by the plan tree.
--- 25,42 ----
unnecessarily (for example, Sort does not rescan its input if no parameters
of the input have changed, since it can just reread its stored sorted data).
! It is only necessary to deliver the top-level result tuples to the client.
! If the query is a SELECT, the topmost plan node is the output of the SELECT.
! If the query is a DML operation, a DML node is added to the top, which calls
! its child nodes to fetch the tuples. If the DML operation has a RETURNING
! clause the node will output the projected tuples, otherwise it gives out
! dummy tuples until it has processed all tuples from its child nodes. After
! that, it gives NULL.
!
! Handling INSERT is pretty straightforward: the tuples returned from the
! subtree are inserted into the correct result relation. In addition to the
! tuple value, UPDATE needs a "junk" (hidden) tuple CTID identifying the
! target tuple. The DML node needs this information to update the correct
tuple. DELETE is similar to UPDATE except that only a CTID need be
delivered by the plan tree.
