diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2008-07-26 19:15:35 +0000 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2008-07-26 19:15:35 +0000 |
commit | a77eaa6a95009a3441e0d475d1980259d45da072 (patch) | |
tree | e1f8f0f7e915ad440d9f7407a80d7b452034b133 /src/backend/executor/execAmi.c | |
parent | 94be06af76ac85e362c42bff5824a5cd04860934 (diff) |
As noted by Andrew Gierth, there's really no need any more to force a junk
filter to be used when INSERT or SELECT INTO has a plan that returns raw
disk tuples. The virtual-tuple-slot optimizations that were put in place
awhile ago mean that ExecInsert has to do ExecMaterializeSlot, and that
already copies the tuple if it's raw (and does so more efficiently than
a junk filter, too). So get rid of that logic. This in turn means that
we can throw away ExecMayReturnRawTuples, which wasn't used for any other
purpose, and was always a kluge anyway.
In passing, move a couple of SELECT-INTO-specific fields out of EState
and into the private state of the SELECT INTO DestReceiver, as was foreseen
in an old comment there. Also make intorel_receive use ExecMaterializeSlot
not ExecCopySlotTuple, for consistency with ExecInsert and to possibly save
a tuple copy step in some cases.
Diffstat (limited to 'src/backend/executor/execAmi.c')
-rw-r--r-- | src/backend/executor/execAmi.c | 71 |
1 files changed, 1 insertions, 70 deletions
diff --git a/src/backend/executor/execAmi.c b/src/backend/executor/execAmi.c index b637b5a08f2..154301a67f9 100644 --- a/src/backend/executor/execAmi.c +++ b/src/backend/executor/execAmi.c @@ -6,7 +6,7 @@ * Portions Copyright (c) 1996-2008, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/backend/executor/execAmi.c,v 1.95 2008/07/10 01:17:29 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/executor/execAmi.c,v 1.96 2008/07/26 19:15:35 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -424,72 +424,3 @@ ExecSupportsBackwardScan(Plan *node) return false; } } - -/* - * ExecMayReturnRawTuples - * Check whether a plan tree may return "raw" disk tuples (that is, - * pointers to original data in disk buffers, as opposed to temporary - * tuples constructed by projection steps). In the case of Append, - * some subplans may return raw tuples and others projected tuples; - * we return "true" if any of the returned tuples could be raw. - * - * This must be passed an already-initialized planstate tree, because we - * need to look at the results of ExecAssignScanProjectionInfo(). - */ -bool -ExecMayReturnRawTuples(PlanState *node) -{ - /* - * At a table scan node, we check whether ExecAssignScanProjectionInfo - * decided to do projection or not. Most non-scan nodes always project - * and so we can return "false" immediately. For nodes that don't project - * but just pass up input tuples, we have to recursively examine the input - * plan node. - * - * Note: Hash and Material are listed here because they sometimes return - * an original input tuple, not a copy. But Sort and SetOp never return - * an original tuple, so they can be treated like projecting nodes. - */ - switch (nodeTag(node)) - { - /* Table scan nodes */ - case T_SeqScanState: - case T_IndexScanState: - case T_BitmapHeapScanState: - case T_TidScanState: - if (node->ps_ProjInfo == NULL) - return true; - break; - - case T_SubqueryScanState: - /* If not projecting, look at input plan */ - if (node->ps_ProjInfo == NULL) - return ExecMayReturnRawTuples(((SubqueryScanState *) node)->subplan); - break; - - /* Non-projecting nodes */ - case T_HashState: - case T_MaterialState: - case T_UniqueState: - case T_LimitState: - return ExecMayReturnRawTuples(node->lefttree); - - case T_AppendState: - { - AppendState *appendstate = (AppendState *) node; - int j; - - for (j = 0; j < appendstate->as_nplans; j++) - { - if (ExecMayReturnRawTuples(appendstate->appendplans[j])) - return true; - } - break; - } - - /* All projecting node types come here */ - default: - break; - } - return false; -} |