Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitbc3087b

Browse files
Harmonize nbtree page split point code.
An nbtree split point can be thought of as a point between two adjoiningtuples from an imaginary version of the page being split that includesthe incoming/new item (in addition to the items that really are on thepage). These adjoining tuples are called the lastleft and firstrighttuples.The variables that represent split points contained a field calledfirstright, which is an offset number of the first data item from theoriginal page that goes on the new right page. The corresponding tuplefrom origpage was usually the same thing as the actual firstright tuple,but not always: the firstright tuple is sometimes the new/incoming iteminstead. This situation seems unnecessarily confusing.Make things clearer by renaming the origpage offset returned by_bt_findsplitloc() to "firstrightoff". We now have a firstright tupleand a firstrightoff offset number which are comparable to thenewitem/lastleft tuples and the newitemoff/lastleftoff offset numbersrespectively. Also make sure that we are consistent about how wedescribe nbtree page split point state.Push the responsibility for dealing with pg_upgrade'd !heapkeyspaceindexes down to lower level code, relieving _bt_split() from dealingwith it directly. This means that we always have a palloc'd left pagehigh key on the leaf level, no matter what. This enables simplifyingsome of the code (and code comments) within _bt_split().Finally, restructure the page split code to make it clearer why suffixtruncation (which only takes place during leaf page splits) iscompletely different to the first data item truncation that takes placeduring internal page splits. Tuples are marked as having fewerattributes stored in both cases, and the firstright tuple is truncatedin both cases, so it's easy to imagine somebody missing the distinction.
1 parent8f00d84 commitbc3087b

File tree

8 files changed

+334
-291
lines changed

8 files changed

+334
-291
lines changed

‎contrib/amcheck/verify_nbtree.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1121,7 +1121,7 @@ bt_target_page_check(BtreeCheckState *state)
11211121
* designated purpose. Enforce the lower limit for pivot tuples when
11221122
* an explicit heap TID isn't actually present. (In all other cases
11231123
* suffix truncation is guaranteed to generate a pivot tuple that's no
1124-
* larger than thefirst right tuple provided to it by its caller.)
1124+
* larger than thefirstright tuple provided to it by its caller.)
11251125
*/
11261126
lowersizelimit=skey->heapkeyspace&&
11271127
(P_ISLEAF(topaque)||BTreeTupleGetHeapTID(itup)==NULL);

‎src/backend/access/nbtree/nbtinsert.c

Lines changed: 190 additions & 153 deletions
Large diffs are not rendered by default.

‎src/backend/access/nbtree/nbtsort.c

Lines changed: 22 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -269,7 +269,8 @@ static Page _bt_blnewpage(uint32 level);
269269
staticBTPageState*_bt_pagestate(BTWriteState*wstate,uint32level);
270270
staticvoid_bt_slideleft(Pagepage);
271271
staticvoid_bt_sortaddtup(Pagepage,Sizeitemsize,
272-
IndexTupleitup,OffsetNumberitup_off);
272+
IndexTupleitup,OffsetNumberitup_off,
273+
boolnewfirstdataitem);
273274
staticvoid_bt_buildadd(BTWriteState*wstate,BTPageState*state,
274275
IndexTupleitup,Sizetruncextra);
275276
staticvoid_bt_sort_dedup_finish_pending(BTWriteState*wstate,
@@ -750,26 +751,24 @@ _bt_slideleft(Page page)
750751
/*
751752
* Add an item to a page being built.
752753
*
753-
* The main difference between this routine and a bare PageAddItem call
754-
* is that this code knows that the leftmost data item on a non-leaf btree
755-
* page has a key that must be treated as minus infinity. Therefore, it
756-
* truncates away all attributes.
754+
* This is very similar to nbtinsert.c's _bt_pgaddtup(), but this variant
755+
* raises an error directly.
757756
*
758-
*This is almost like nbtinsert.c's _bt_pgaddtup(), but we can't use
759-
*that because it assumes that P_RIGHTMOST() will returnthecorrect
760-
*answer for the page. Here, we don't know yet if the page will be
761-
*rightmost. Offset P_FIRSTKEY is always the first data key.
757+
*Note that our nbtsort.c caller does not know yet if the page will be
758+
*rightmost. Offset P_FIRSTKEY is always assumed to bethefirst data key by
759+
*caller. Page that turns out to be the rightmost on its level is fixed by
760+
*calling _bt_slideleft().
762761
*/
763762
staticvoid
764763
_bt_sortaddtup(Pagepage,
765764
Sizeitemsize,
766765
IndexTupleitup,
767-
OffsetNumberitup_off)
766+
OffsetNumberitup_off,
767+
boolnewfirstdataitem)
768768
{
769-
BTPageOpaqueopaque= (BTPageOpaque)PageGetSpecialPointer(page);
770769
IndexTupleDatatrunctuple;
771770

772-
if (!P_ISLEAF(opaque)&&itup_off==P_FIRSTKEY)
771+
if (newfirstdataitem)
773772
{
774773
trunctuple=*itup;
775774
trunctuple.t_info=sizeof(IndexTupleData);
@@ -867,12 +866,13 @@ _bt_buildadd(BTWriteState *wstate, BTPageState *state, IndexTuple itup,
867866
* Every newly built index will treat heap TID as part of the keyspace,
868867
* which imposes the requirement that new high keys must occasionally have
869868
* a heap TID appended within _bt_truncate(). That may leave a new pivot
870-
* tuple one or two MAXALIGN() quantums larger than the original first
871-
* right tuple it's derived from. v4 deals with the problem by decreasing
872-
* the limit on the size of tuples inserted on the leaf level by the same
873-
* small amount. Enforce the new v4+ limit on the leaf level, and the old
874-
* limit on internal levels, since pivot tuples may need to make use of
875-
* the reserved space. This should never fail on internal pages.
869+
* tuple one or two MAXALIGN() quantums larger than the original
870+
* firstright tuple it's derived from. v4 deals with the problem by
871+
* decreasing the limit on the size of tuples inserted on the leaf level
872+
* by the same small amount. Enforce the new v4+ limit on the leaf level,
873+
* and the old limit on internal levels, since pivot tuples may need to
874+
* make use of the reserved space. This should never fail on internal
875+
* pages.
876876
*/
877877
if (unlikely(itupsz>BTMaxItemSize(npage)))
878878
_bt_check_third_page(wstate->index,wstate->heap,isleaf,npage,
@@ -925,7 +925,8 @@ _bt_buildadd(BTWriteState *wstate, BTPageState *state, IndexTuple itup,
925925
Assert(last_off>P_FIRSTKEY);
926926
ii=PageGetItemId(opage,last_off);
927927
oitup= (IndexTuple)PageGetItem(opage,ii);
928-
_bt_sortaddtup(npage,ItemIdGetLength(ii),oitup,P_FIRSTKEY);
928+
_bt_sortaddtup(npage,ItemIdGetLength(ii),oitup,P_FIRSTKEY,
929+
!isleaf);
929930

930931
/*
931932
* Move 'last' into the high key position on opage. _bt_blnewpage()
@@ -1054,7 +1055,8 @@ _bt_buildadd(BTWriteState *wstate, BTPageState *state, IndexTuple itup,
10541055
* Add the new item into the current page.
10551056
*/
10561057
last_off=OffsetNumberNext(last_off);
1057-
_bt_sortaddtup(npage,itupsz,itup,last_off);
1058+
_bt_sortaddtup(npage,itupsz,itup,last_off,
1059+
!isleaf&&last_off==P_FIRSTKEY);
10581060

10591061
state->btps_page=npage;
10601062
state->btps_blkno=nblkno;

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp