Revise TupleTableSlot code to avoid unnecessary construction and disassembly

of tuples when passing data up through multiple plan nodes.  A slot can now
hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting
of Datum/isnull arrays.  Upper plan levels can usually just copy the Datum
arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr()
calls to extract the data again.  This work extends Atsushi Ogawa's earlier
patch, which provided the key idea of adding Datum arrays to TupleTableSlots.
(I believe however that something like this was foreseen way back in Berkeley
days --- see the old comment on ExecProject.)  A test case involving many
levels of join of fairly wide tables (about 80 columns altogether) showed
about 3x overall speedup, though simple queries will probably not be
helped very much.

I have also duplicated some code in heaptuple.c in order to provide versions
of heap_formtuple and friends that use "bool" arrays to indicate null
attributes, instead of the old convention of "char" arrays containing either
'n' or ' '.  This provides a better match to the convention used by
ExecEvalExpr.  While I have not made a concerted effort to get rid of uses
of the old routines, I think they should be deprecated and eventually removed.

1 files changed, 3 insertions, 16 deletions

diff --git a/src/backend/executor/nodeLimit.c b/src/backend/executor/nodeLimit.c
index b4942d62907..40e0283e86f 100644
--- a/src/backend/executor/nodeLimit.c
+++ b/src/backend/executor/nodeLimit.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/executor/nodeLimit.c,v 1.20 2004/12/31 21:59:45 pgsql Exp $
+ *	  $PostgreSQL: pgsql/src/backend/executor/nodeLimit.c,v 1.21 2005/03/16 21:38:07 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -38,7 +38,6 @@ TupleTableSlot *				/* return: a tuple or NULL */
 ExecLimit(LimitState *node)
 {
 	ScanDirection direction;
-	TupleTableSlot *resultTupleSlot;
 	TupleTableSlot *slot;
 	PlanState  *outerPlan;
 
@@ -47,7 +46,6 @@ ExecLimit(LimitState *node)
 	 */
 	direction = node->ps.state->es_direction;
 	outerPlan = outerPlanState(node);
-	resultTupleSlot = node->ps.ps_ResultTupleSlot;
 
 	/*
 	 * The main logic is a simple state machine.
@@ -219,12 +217,7 @@ ExecLimit(LimitState *node)
 	/* Return the current tuple */
 	Assert(!TupIsNull(slot));
 
-	ExecStoreTuple(slot->val,
-				   resultTupleSlot,
-				   InvalidBuffer,
-				   false);		/* tuple does not belong to slot */
-
-	return resultTupleSlot;
+	return slot;
 }
 
 /*
@@ -324,7 +317,7 @@ ExecInitLimit(Limit *node, EState *estate)
 #define LIMIT_NSLOTS 1
 
 	/*
-	 * Tuple table initialization
+	 * Tuple table initialization (XXX not actually used...)
 	 */
 	ExecInitResultTupleSlot(estate, &limitstate->ps);
 
@@ -363,10 +356,6 @@ void
 ExecEndLimit(LimitState *node)
 {
 	ExecFreeExprContext(&node->ps);
-
-	/* clean up tuple table */
-	ExecClearTuple(node->ps.ps_ResultTupleSlot);
-
 	ExecEndNode(outerPlanState(node));
 }
 
@@ -377,8 +366,6 @@ ExecReScanLimit(LimitState *node, ExprContext *exprCtxt)
 	/* resetting lstate will force offset/limit recalculation */
 	node->lstate = LIMIT_INITIAL;
 
-	ExecClearTuple(node->ps.ps_ResultTupleSlot);
-
 	/*
 	 * if chgParam of subnode is not null then plan will be re-scanned by
 	 * first ExecProcNode.