Some incorrect comments and out-dated README from run-time pruning

diff --git a/src/backend/executor/README b/src/backend/executor/README
index 0d7cd552eb..ddbd62b4db 100644
--- a/src/backend/executor/README
+++ b/src/backend/executor/README
@@ -45,13 +45,21 @@ Plan Trees and State Trees
 
 The plan tree delivered by the planner contains a tree of Plan nodes (struct
 types derived from struct Plan).  During executor startup we build a parallel
-tree of identical structure containing executor state nodes --- every plan
-node type has a corresponding executor state node type.  Each node in the
-state tree has a pointer to its corresponding node in the plan tree, plus
-executor state data as needed to implement that node type.  This arrangement
-allows the plan tree to be completely read-only so far as the executor is
-concerned: all data that is modified during execution is in the state tree.
-Read-only plan trees make life much simpler for plan caching and reuse.
+tree of identical structure containing executor state nodes --- generally,
+every plan node type has a corresponding executor state node type.  Each node
+in the state tree has a pointer to its corresponding node in the plan tree,
+plus executor state data as needed to implement that node type.  This
+arrangement allows the plan tree to be completely read-only so far as the
+executor is concerned: all data that is modified during execution is in the
+state tree.  Read-only plan trees make life much simpler for plan caching and
+reuse.
+
+A corresponding executor state node may not be created during executor startup
+if the executor determines that an entire subplan is not required due to
+execution time partition pruning determining that no matching records will be
+found there.  This currently only occurs for Append and MergeAppend nodes.  In
+this case the non-required subplans are ignored and the executor state's
+subnode array will become out of sequence to the plan's subplan list.
 
 Each Plan node may have expression trees associated with it, to represent
 its target list, qualification conditions, etc.  These trees are also
diff --git a/src/include/nodes/plannodes.h b/src/include/nodes/plannodes.h
index 5e3d4cdc58..cb650af66c 100644
--- a/src/include/nodes/plannodes.h
+++ b/src/include/nodes/plannodes.h
@@ -1084,15 +1084,16 @@ typedef struct PartitionPruneInfo
  * PartitionedRelPruneInfo - Details required to allow the executor to prune
  * partitions for a single partitioned table.
  *
- * subplan_map[] and subpart_map[] are indexed by partition index (where
- * zero is the topmost partition, and non-leaf partitions must come before
- * their children).  For a leaf partition p, subplan_map[p] contains the
- * zero-based index of the partition's subplan in the parent plan's subplan
- * list; it is -1 if the partition is non-leaf or has been pruned.  For a
- * non-leaf partition p, subpart_map[p] contains the zero-based index of
- * that sub-partition's PartitionedRelPruneInfo in the hierarchy's
- * PartitionedRelPruneInfo list; it is -1 if the partition is a leaf or has
- * been pruned.  Note that subplan indexes are global across the parent plan
+ * subplan_map[] and subpart_map[] are indexed by partition index of the
+ * partitioned table referenced by 'rtindex'.  The partition index being the
+ * order that the partitions are defined in the table's PartitionDesc.  For a
+ * leaf partition p, subplan_map[p] contains the zero-based index of the
+ * partition's subplan in the parent plan's subplan list; it is -1 if the
+ * partition is non-leaf or has been pruned.  For a non-leaf partition p,
+ * subpart_map[p] contains the zero-based index of that sub-partition's
+ * PartitionedRelPruneInfo in the hierarchy's PartitionedRelPruneInfo list;
+ * it is -1 if the partition is a leaf or has been pruned.  Note that subplan
+ * indexes, as stored in 'subplan_map', are global across the parent plan
  * node, but partition indexes are valid only within a particular hierarchy.
  */
 typedef struct PartitionedRelPruneInfo