From: Vadim B. Mikheev <vadim4o@yahoo.com>
Date: Sat, 1 May 1999 15:04:46 +0000 (+0000)
Subject: Use page-level ExtendLock lock instead of table-level -
X-Git-Tag: REL6_5~328
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=34a84addc7208ce6e37ae2afd8f3023f0f9340a5;p=postgresql

Use page-level ExtendLock lock instead of table-level -
should be faster.
---

diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c
index f827f6e421..3b4fa4af0b 100644
--- a/src/backend/access/heap/hio.c
+++ b/src/backend/access/heap/hio.c
@@ -7,7 +7,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Id: hio.c,v 1.17 1999/02/13 23:14:24 momjian Exp $
+ *	  $Id: hio.c,v 1.18 1999/05/01 15:04:46 vadim Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -110,8 +110,15 @@ RelationPutHeapTupleAtEnd(Relation relation, HeapTuple tuple)
 	ItemId		itemId;
 	Item		item;
 
+	/*
+	 * Actually, we lock _relation_ here, not page, but I believe
+	 * that locking page is faster... Obviously, we could get rid
+	 * of ExtendLock mode at all and use ExclusiveLock mode on
+	 * page 0, as long as we use page-level locking for indices only,
+	 * but we are in 6.5-beta currently...	- vadim 05/01/99
+	 */
 	if (!relation->rd_myxactonly)
-		LockRelation(relation, ExtendLock);
+		LockPage(relation, 0, ExtendLock);
 
 	/*
 	 * XXX This does an lseek - VERY expensive - but at the moment it is
@@ -159,7 +166,7 @@ RelationPutHeapTupleAtEnd(Relation relation, HeapTuple tuple)
 	}
 
 	if (!relation->rd_myxactonly)
-		UnlockRelation(relation, ExtendLock);
+		UnlockPage(relation, 0, ExtendLock);
 
 	offnum = PageAddItem((Page) pageHeader, (Item) tuple->t_data,
 						 tuple->t_len, InvalidOffsetNumber, LP_USED);