pgsql: Use "low key" terminology in nbtsort.c. - Mailing list pgsql-committers

From Peter Geoghegan
Subject pgsql: Use "low key" terminology in nbtsort.c.
Date
Msg-id E1iSspF-0007zO-E3@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Use "low key" terminology in nbtsort.c.

nbtree index builds once stashed the "minimum key" for a page, which was
used as the basis of the pivot tuple that gets placed in the next level
up (i.e. the tuple that stores the downlink to the page in question).
It doesn't quite work that way anymore, so the "minimum key" terminology
now seems misleading (these days the minimum key is actually a straight
copy of the high key from the left sibling, which is a distinct thing in
subtle but important ways).  Rename this concept to "low key".  This
name is a lot clearer given that there is now a sharp distinction
between pivot and non-pivot tuples.  Also remove comments that describe
obsolete details about how the minimum key concept used to work.

Rather than generating the minus infinity item for the leftmost page on
a level by copying the new item and truncating that copy, simply
allocate a small buffer.  The old approach confusingly created the
impression that the new item had some kind of significance.  This was
another artifact of how things used to work before commits 8224de4f and
dd299df8.

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/e86c8ef243aad4570f66a406c81211f75774ced1

Modified Files
--------------
src/backend/access/nbtree/nbtsort.c | 69 ++++++++++++++++---------------------
1 file changed, 29 insertions(+), 40 deletions(-)


pgsql-committers by date:

Previous
From: Bruce Momjian
Date:
Subject: pgsql: docs: clarify that only INSERT and UPDATE triggers can mod. NEW
Next
From: Peter Eisentraut
Date:
Subject: pgsql: More precise errors from initial pg_control check