pgsql: Use "low key" terminology in nbtsort.c.

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема pgsql: Use "low key" terminology in nbtsort.c.
Дата
Msg-id E1iSspF-0007zO-E3@gemulon.postgresql.org
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: pgsql: docs: clarify that only INSERT and UPDATE triggers can mod. NEW
Следующее
От: Peter Eisentraut
Дата:
Сообщение: pgsql: More precise errors from initial pg_control check