diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2009-09-27 20:09:58 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2009-09-27 20:09:58 +0000 |
| commit | f92e8a4b5ee6a22252cbba012d629f5cefef913f (patch) | |
| tree | 93171ec5198f1f5e4463289bf8c1050c1383741a /src/backend/executor/nodeSubplan.c | |
| parent | 61be11ff088c1e2b22c7e2af6f93ccdc286dba01 (diff) | |
| download | postgresql-f92e8a4b5ee6a22252cbba012d629f5cefef913f.tar.gz postgresql-f92e8a4b5ee6a22252cbba012d629f5cefef913f.zip | |
Replace the array-style TupleTable data structure with a simple List of
TupleTableSlot nodes. This eliminates the need to count in advance
how many Slots will be needed, which seems more than worth the small
increase in the amount of palloc traffic during executor startup.
The ExecCountSlots infrastructure is now all dead code, but I'll remove it
in a separate commit for clarity.
Per a comment from Robert Haas.
Diffstat (limited to 'src/backend/executor/nodeSubplan.c')
| -rw-r--r-- | src/backend/executor/nodeSubplan.c | 16 |
1 files changed, 3 insertions, 13 deletions
diff --git a/src/backend/executor/nodeSubplan.c b/src/backend/executor/nodeSubplan.c index 016dbc378b4..753655e9a49 100644 --- a/src/backend/executor/nodeSubplan.c +++ b/src/backend/executor/nodeSubplan.c @@ -7,7 +7,7 @@ * Portions Copyright (c) 1994, Regents of the University of California * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/executor/nodeSubplan.c,v 1.99 2009/06/11 14:48:57 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/executor/nodeSubplan.c,v 1.100 2009/09/27 20:09:57 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -721,7 +721,6 @@ ExecInitSubPlan(SubPlan *subplan, PlanState *parent) int ncols, i; TupleDesc tupDesc; - TupleTable tupTable; TupleTableSlot *slot; List *oplist, *lefttlist, @@ -853,15 +852,6 @@ ExecInitSubPlan(SubPlan *subplan, PlanState *parent) } /* - * Create a tupletable to hold these tuples. (Note: we never bother - * to free the tupletable explicitly; that's okay because it will - * never store raw disk tuples that might have associated buffer pins. - * The only resource involved is memory, which will be cleaned up by - * freeing the query context.) - */ - tupTable = ExecCreateTupleTable(2); - - /* * Construct tupdescs, slots and projection nodes for left and right * sides. The lefthand expressions will be evaluated in the parent * plan node's exprcontext, which we don't have access to here. @@ -870,7 +860,7 @@ ExecInitSubPlan(SubPlan *subplan, PlanState *parent) * own innerecontext. */ tupDesc = ExecTypeFromTL(leftptlist, false); - slot = ExecAllocTableSlot(tupTable); + slot = ExecInitExtraTupleSlot(estate); ExecSetSlotDescriptor(slot, tupDesc); sstate->projLeft = ExecBuildProjectionInfo(lefttlist, NULL, @@ -878,7 +868,7 @@ ExecInitSubPlan(SubPlan *subplan, PlanState *parent) NULL); tupDesc = ExecTypeFromTL(rightptlist, false); - slot = ExecAllocTableSlot(tupTable); + slot = ExecInitExtraTupleSlot(estate); ExecSetSlotDescriptor(slot, tupDesc); sstate->projRight = ExecBuildProjectionInfo(righttlist, sstate->innerecontext, |