From 37fa3b6c89abc05f8c4691440a27427db3a6e03b Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 21 Apr 2004 18:24:26 +0000 Subject: Tweak indexscan and seqscan code to arrange that steps from one page to the next are handled by ReleaseAndReadBuffer rather than separate ReleaseBuffer and ReadBuffer calls. This cuts the number of acquisitions of the BufMgrLock by a factor of 2 (possibly more, if an indexscan happens to pull successive rows from the same heap page). Unfortunately this doesn't seem enough to get us out of the recently discussed context-switch storm problem, but it's surely worth doing anyway. --- src/backend/executor/nodeTidscan.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'src/backend/executor/nodeTidscan.c') diff --git a/src/backend/executor/nodeTidscan.c b/src/backend/executor/nodeTidscan.c index 2ee58655ed6..ee928deff5d 100644 --- a/src/backend/executor/nodeTidscan.c +++ b/src/backend/executor/nodeTidscan.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/executor/nodeTidscan.c,v 1.36 2003/11/29 19:51:48 pgsql Exp $ + * $PostgreSQL: pgsql/src/backend/executor/nodeTidscan.c,v 1.37 2004/04/21 18:24:26 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -106,6 +106,13 @@ TidNext(TidScanState *node) slot = node->ss.ss_ScanTupleSlot; scanrelid = ((TidScan *) node->ss.ps.plan)->scan.scanrelid; + /* + * Clear any reference to the previously returned tuple. This doesn't + * offer any great performance benefit, but it keeps this code in sync + * with SeqNext and IndexNext. + */ + 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 @@ -115,7 +122,6 @@ TidNext(TidScanState *node) if (estate->es_evTuple != NULL && estate->es_evTuple[scanrelid - 1] != NULL) { - ExecClearTuple(slot); if (estate->es_evTupleNull[scanrelid - 1]) return slot; /* return empty slot */ -- cgit v1.2.3