database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-13 07:41:39 +03:00
Code Activity

Improve ExecStoreTuple to be smarter about replacing the contents of

Browse Source 
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.
This commit is contained in:
Tom Lane
2005-11-25 04:24:48 +00:00
parent c0a2f8cc4d
commit dab52ab13d
5 changed files with 33 additions and 55 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
src/backend/executor/nodeBitmapHeapscan.c
View File

@ -21,7 +21,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/executor/nodeBitmapHeapscan.c,v 1.4 2005/10/15 02:49:17 momjian Exp $
* $PostgreSQL: pgsql/src/backend/executor/nodeBitmapHeapscan.c,v 1.5 2005/11/25 04:24:48 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -75,15 +75,6 @@ BitmapHeapNext(BitmapHeapScanState *node)
tbm = node->tbm;
tbmres = node->tbmres;
/*
* 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, below.
*/
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
@ -94,7 +85,7 @@ BitmapHeapNext(BitmapHeapScanState *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);