aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeIndexscan.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2005-11-25 04:24:48 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2005-11-25 04:24:48 +0000
commitdab52ab13d3d3cce26e9bcc3193eb285c195d430 (patch)
treed7b4ebc7af6d4e09341637179e46d212c69070af /src/backend/executor/nodeIndexscan.c
parentc0a2f8cc4decba933f0ebb6d5b4ffd9eca036a78 (diff)
downloadpostgresql-dab52ab13d3d3cce26e9bcc3193eb285c195d430.tar.gz
postgresql-dab52ab13d3d3cce26e9bcc3193eb285c195d430.zip
Improve ExecStoreTuple to be smarter about replacing the contents of
a TupleTableSlot: instead of calling ExecClearTuple, inline the needed operations, so that we can avoid redundant steps. In particular, when the old and new tuples are both on the same disk page, avoid releasing and re-acquiring the buffer pin --- this saves work in both the bufmgr and ResourceOwner modules. To make this improvement actually useful, partially revert a change I made on 2004-04-21 that caused SeqNext et al to call ExecClearTuple before ExecStoreTuple. The motivation for that, to avoid grabbing the BufMgrLock separately for releasing the old buffer and grabbing the new one, no longer applies. My profiling says that this saves about 5% of the CPU time for an all-in-memory seqscan.
Diffstat (limited to 'src/backend/executor/nodeIndexscan.c')
-rw-r--r--src/backend/executor/nodeIndexscan.c13
1 files changed, 2 insertions, 11 deletions
diff --git a/src/backend/executor/nodeIndexscan.c b/src/backend/executor/nodeIndexscan.c
index 6e639502c1d..4f6fadfde49 100644
--- a/src/backend/executor/nodeIndexscan.c
+++ b/src/backend/executor/nodeIndexscan.c
@@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/executor/nodeIndexscan.c,v 1.105 2005/11/22 18:17:10 momjian Exp $
+ * $PostgreSQL: pgsql/src/backend/executor/nodeIndexscan.c,v 1.106 2005/11/25 04:24:48 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -75,15 +75,6 @@ IndexNext(IndexScanState *node)
scanrelid = ((IndexScan *) node->ss.ps.plan)->scan.scanrelid;
/*
- * Clear any reference to the previously returned tuple. The idea here is
- * to not have the tuple slot be the last holder of a pin on that tuple's
- * buffer; if it is, we'll need a separate visit to the bufmgr to release
- * the buffer. By clearing here, we get to have the release done by
- * ReleaseAndReadBuffer inside index_getnext.
- */
- ExecClearTuple(slot);
-
- /*
* Check if we are evaluating PlanQual for tuple of this relation.
* Additional checking is not good, but no other way for now. We could
* introduce new nodes for this case and handle IndexScan --> NewNode
@@ -93,7 +84,7 @@ IndexNext(IndexScanState *node)
estate->es_evTuple[scanrelid - 1] != NULL)
{
if (estate->es_evTupleNull[scanrelid - 1])
- return slot; /* return empty slot */
+ return ExecClearTuple(slot);
ExecStoreTuple(estate->es_evTuple[scanrelid - 1],
slot, InvalidBuffer, false);