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

Make heap_fetch API more consistent by having the buffer remain pinned

Browse Source 
in all cases when keep_buf = true.  This allows ANALYZE's inner loop to
use heap_release_fetch, which saves multiple buffer lookups for the same
page and avoids overestimation of cost by the vacuum cost mechanism.
This commit is contained in:
Tom Lane
2004-10-26 16:05:03 +00:00
parent 2c66dcf684
commit 83cd2d8b0f
3 changed files with 31 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
src/backend/access/heap/heapam.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/access/heap/heapam.c,v 1.179 2004/10/15 22:39:42 tgl Exp $
* $PostgreSQL: pgsql/src/backend/access/heap/heapam.c,v 1.180 2004/10/26 16:05:02 tgl Exp $
*
*
* INTERFACE ROUTINES
@ -878,14 +878,16 @@ heap_getnext(HeapScanDesc scan, ScanDirection direction)
* is set to the buffer holding the tuple and TRUE is returned. The caller
* must unpin the buffer when done with the tuple.
*
* If the tuple is not found, then tuple->t_data is set to NULL, *userbuf
* is set to InvalidBuffer, and FALSE is returned.
* If the tuple is not found (ie, item number references a deleted slot),
* then tuple->t_data is set to NULL and FALSE is returned.
*
* If the tuple is found but fails the time qual check, then FALSE will be
* returned. When the caller specifies keep_buf = true, we retain the pin
* on the buffer and return it in *userbuf (so the caller can still access
* the tuple); when keep_buf = false, the pin is released and *userbuf is set
* to InvalidBuffer.
* If the tuple is found but fails the time qual check, then FALSE is returned
* but tuple->t_data is left pointing to the tuple.
*
* keep_buf determines what is done with the buffer in the FALSE-result cases.
* When the caller specifies keep_buf = true, we retain the pin on the buffer
* and return it in *userbuf (so the caller must eventually unpin it); when
* keep_buf = false, the pin is released and *userbuf is set to InvalidBuffer.
*
* It is somewhat inconsistent that we ereport() on invalid block number but
* return false on invalid item number. This is historical. The only
@ -914,6 +916,8 @@ heap_fetch(Relation relation,
* InvalidBuffer on entry, that buffer will be released before reading
* the new page. This saves a separate ReleaseBuffer step and hence
* one entry into the bufmgr when looping through multiple fetches.
* Also, if *userbuf is the same buffer that holds the target tuple,
* we avoid bufmgr manipulation altogether.
*/
bool
heap_release_fetch(Relation relation,
@ -962,8 +966,13 @@ heap_release_fetch(Relation relation,
if (!ItemIdIsUsed(lp))
{
LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
ReleaseBuffer(buffer);
*userbuf = InvalidBuffer;
if (keep_buf)
*userbuf = buffer;
else
{
ReleaseBuffer(buffer);
*userbuf = InvalidBuffer;
}
tuple->t_datamcxt = NULL;
tuple->t_data = NULL;
return false;
@ -1007,17 +1016,13 @@ heap_release_fetch(Relation relation,
/* Tuple failed time qual, but maybe caller wants to see it anyway. */
if (keep_buf)
{
*userbuf = buffer;
return false;
else
{
ReleaseBuffer(buffer);
*userbuf = InvalidBuffer;
}
/* Okay to release pin on buffer. */
ReleaseBuffer(buffer);
*userbuf = InvalidBuffer;
return false;
}