mirror of
https://github.com/postgres/postgres.git
synced 2025-10-21 02:52:47 +03:00
Harmonize nbtree page split point code.
An nbtree split point can be thought of as a point between two adjoining tuples from an imaginary version of the page being split that includes the incoming/new item (in addition to the items that really are on the page). These adjoining tuples are called the lastleft and firstright tuples. The variables that represent split points contained a field called firstright, which is an offset number of the first data item from the original page that goes on the new right page. The corresponding tuple from origpage was usually the same thing as the actual firstright tuple, but not always: the firstright tuple is sometimes the new/incoming item instead. This situation seems unnecessarily confusing. Make things clearer by renaming the origpage offset returned by _bt_findsplitloc() to "firstrightoff". We now have a firstright tuple and a firstrightoff offset number which are comparable to the newitem/lastleft tuples and the newitemoff/lastleftoff offset numbers respectively. Also make sure that we are consistent about how we describe nbtree page split point state. Push the responsibility for dealing with pg_upgrade'd !heapkeyspace indexes down to lower level code, relieving _bt_split() from dealing with it directly. This means that we always have a palloc'd left page high key on the leaf level, no matter what. This enables simplifying some of the code (and code comments) within _bt_split(). Finally, restructure the page split code to make it clearer why suffix truncation (which only takes place during leaf page splits) is completely different to the first data item truncation that takes place during internal page splits. Tuples are marked as having fewer attributes stored in both cases, and the firstright tuple is truncated in both cases, so it's easy to imagine somebody missing the distinction.
This commit is contained in:
@@ -99,9 +99,9 @@ typedef struct xl_btree_insert
|
||||
* left or right split page (and thus, whether the new item is stored or not).
|
||||
* We always log the left page high key because suffix truncation can generate
|
||||
* a new leaf high key using user-defined code. This is also necessary on
|
||||
* internal pages, since the first right item that the left page's high key
|
||||
* was based on will have been truncated to zero attributes in the right page
|
||||
* (the original is unavailable from the right page).
|
||||
* internal pages, since the firstright item that the left page's high key was
|
||||
* based on will have been truncated to zero attributes in the right page (the
|
||||
* separator key is unavailable from the right page).
|
||||
*
|
||||
* Backup Blk 0: original page / new left page
|
||||
*
|
||||
@@ -153,7 +153,7 @@ typedef struct xl_btree_insert
|
||||
typedef struct xl_btree_split
|
||||
{
|
||||
uint32 level; /* tree level of page being split */
|
||||
OffsetNumber firstright; /* first item moved to right page */
|
||||
OffsetNumber firstrightoff; /* first origpage item on rightpage */
|
||||
OffsetNumber newitemoff; /* new item's offset */
|
||||
uint16 postingoff; /* offset inside orig posting tuple */
|
||||
} xl_btree_split;
|
||||
|
Reference in New Issue
Block a user