Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit e25d462

Browse files
nbtree: Rename _bt_search() variables.
Make some of the variable names in _bt_search() consistent with corresponding variables within _bt_getstackbuf(). This naming scheme is clearer because the variable names always express a relationship between the currently locked buffer/page and some other page.
1 parent 641dd16 commit e25d462

File tree

1 file changed

+21
-24
lines changed

1 file changed

+21
-24
lines changed

src/backend/access/nbtree/nbtsearch.c

Lines changed: 21 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -82,9 +82,10 @@ _bt_drop_lock_and_maybe_pin(IndexScanDesc scan, BTScanPos sp)
8282
* The passed scankey is an insertion-type scankey (see nbtree/README),
8383
* but it can omit the rightmost column(s) of the index.
8484
*
85-
* Return value is a stack of parent-page pointers. *bufP is set to the
86-
* address of the leaf-page buffer, which is locked and pinned. No locks
87-
* are held on the parent pages, however!
85+
* Return value is a stack of parent-page pointers (i.e. there is no entry for
86+
* the leaf level/page). *bufP is set to the address of the leaf-page buffer,
87+
* which is locked and pinned. No locks are held on the parent pages,
88+
* however!
8889
*
8990
* If the snapshot parameter is not NULL, "old snapshot" checking will take
9091
* place during the descent through the tree. This is not needed when
@@ -118,21 +119,20 @@ _bt_search(Relation rel, BTScanInsert key, Buffer *bufP, int access,
118119
OffsetNumber offnum;
119120
ItemId itemid;
120121
IndexTuple itup;
121-
BlockNumber blkno;
122-
BlockNumber par_blkno;
122+
BlockNumber child;
123123
BTStack new_stack;
124124

125125
/*
126126
* Race -- the page we just grabbed may have split since we read its
127-
* pointer in the parent (or metapage). If it has, we may need to
128-
* move right to its new sibling. Do that.
127+
* downlink in its parent page (or the metapage). If it has, we may
128+
* need to move right to its new sibling. Do that.
129129
*
130130
* In write-mode, allow _bt_moveright to finish any incomplete splits
131131
* along the way. Strictly speaking, we'd only need to finish an
132132
* incomplete split on the leaf page we're about to insert to, not on
133-
* any of the upper levels (they are taken care of in _bt_getstackbuf,
134-
* if the leaf page is split and we insert to the parent page). But
135-
* this is a good opportunity to finish splits of internal pages too.
133+
* any of the upper levels (internal pages with incomplete splits are
134+
* also taken care of in _bt_getstackbuf). But this is a good
135+
* opportunity to finish splits of internal pages too.
136136
*/
137137
*bufP = _bt_moveright(rel, key, *bufP, (access == BT_WRITE), stack_in,
138138
page_access, snapshot);
@@ -144,25 +144,23 @@ _bt_search(Relation rel, BTScanInsert key, Buffer *bufP, int access,
144144
break;
145145

146146
/*
147-
* Find the appropriate item on the internal page, and get the child
148-
* page that it points to.
147+
* Find the appropriate pivot tuple on this page. Its downlink points
148+
* to the child page that we're about to descend to.
149149
*/
150150
offnum = _bt_binsrch(rel, key, *bufP);
151151
itemid = PageGetItemId(page, offnum);
152152
itup = (IndexTuple) PageGetItem(page, itemid);
153153
Assert(BTreeTupleIsPivot(itup) || !key->heapkeyspace);
154-
blkno = BTreeTupleGetDownLink(itup);
155-
par_blkno = BufferGetBlockNumber(*bufP);
154+
child = BTreeTupleGetDownLink(itup);
156155

157156
/*
158-
* We need to save the location of the pivot tuple we chose in the
159-
* parent page on a stack. If we need to split a page, we'll use the
160-
* stack to work back up to its parent page. If caller ends up
161-
* splitting a page one level down, it usually ends up inserting a new
162-
* pivot tuple/downlink immediately after the location recorded here.
157+
* We need to save the location of the pivot tuple we chose in a new
158+
* stack entry for this page/level. If caller ends up splitting a
159+
* page one level down, it usually ends up inserting a new pivot
160+
* tuple/downlink immediately after the location recorded here.
163161
*/
164162
new_stack = (BTStack) palloc(sizeof(BTStackData));
165-
new_stack->bts_blkno = par_blkno;
163+
new_stack->bts_blkno = BufferGetBlockNumber(*bufP);
166164
new_stack->bts_offset = offnum;
167165
new_stack->bts_parent = stack_in;
168166

@@ -174,8 +172,8 @@ _bt_search(Relation rel, BTScanInsert key, Buffer *bufP, int access,
174172
if (opaque->btpo.level == 1 && access == BT_WRITE)
175173
page_access = BT_WRITE;
176174

177-
/* drop the read lock on the parent page, acquire one on the child */
178-
*bufP = _bt_relandgetbuf(rel, *bufP, blkno, page_access);
175+
/* drop the read lock on the page, then acquire one on its child */
176+
*bufP = _bt_relandgetbuf(rel, *bufP, child, page_access);
179177

180178
/* okay, all set to move down a level */
181179
stack_in = new_stack;
@@ -196,8 +194,7 @@ _bt_search(Relation rel, BTScanInsert key, Buffer *bufP, int access,
196194
* If the page was split between the time that we surrendered our read
197195
* lock and acquired our write lock, then this page may no longer be
198196
* the right place for the key we want to insert. In this case, we
199-
* need to move right in the tree. See Lehman and Yao for an
200-
* excruciatingly precise description.
197+
* need to move right in the tree.
201198
*/
202199
*bufP = _bt_moveright(rel, key, *bufP, true, stack_in, BT_WRITE,
203200
snapshot);

0 commit comments

Comments
 (0)