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

Commit 1b9becd

Browse files
Remove redundant _bt_truncate() comment paragraph.
1 parent bc98e1e commit 1b9becd

File tree

1 file changed

+8
-13
lines changed

1 file changed

+8
-13
lines changed

src/backend/access/nbtree/nbtutils.c

+8-13
Original file line numberDiff line numberDiff line change
@@ -2092,25 +2092,20 @@ btbuildphasename(int64 phasenum)
20922092
* Caller's insertion scankey is used to compare the tuples; the scankey's
20932093
* argument values are not considered here.
20942094
*
2095-
* Sometimes this routine will return a new pivot tuple that takes up more
2096-
* space than firstright, because a new heap TID attribute had to be added to
2097-
* distinguish lastleft from firstright. This should only happen when the
2098-
* caller is in the process of splitting a leaf page that has many logical
2099-
* duplicates, where it's unavoidable.
2100-
*
21012095
* Note that returned tuple's t_tid offset will hold the number of attributes
21022096
* present, so the original item pointer offset is not represented. Caller
21032097
* should only change truncated tuple's downlink. Note also that truncated
21042098
* key attributes are treated as containing "minus infinity" values by
21052099
* _bt_compare().
21062100
*
2107-
* In the worst case (when a heap TID is appended) the size of the returned
2108-
* tuple is the size of the first right tuple plus an additional MAXALIGN()'d
2109-
* item pointer. This guarantee is important, since callers need to stay
2110-
* under the 1/3 of a page restriction on tuple size. If this routine is ever
2111-
* taught to truncate within an attribute/datum, it will need to avoid
2112-
* returning an enlarged tuple to caller when truncation + TOAST compression
2113-
* ends up enlarging the final datum.
2101+
* In the worst case (when a heap TID must be appended to distinguish lastleft
2102+
* from firstright), the size of the returned tuple is the size of firstright
2103+
* plus the size of an additional MAXALIGN()'d item pointer. This guarantee
2104+
* is important, since callers need to stay under the 1/3 of a page
2105+
* restriction on tuple size. If this routine is ever taught to truncate
2106+
* within an attribute/datum, it will need to avoid returning an enlarged
2107+
* tuple to caller when truncation + TOAST compression ends up enlarging the
2108+
* final datum.
21142109
*/
21152110
IndexTuple
21162111
_bt_truncate(Relation rel, IndexTuple lastleft, IndexTuple firstright,

0 commit comments

Comments
 (0)