@@ -6,7 +6,7 @@ Heap Only Tuples (HOT)
66The Heap Only Tuple (HOT) feature eliminates redundant index entries and
77allows the re-use of space taken by DELETEd or obsoleted UPDATEd tuples
88without performing a table-wide vacuum. It does this by allowing
9- single-page vacuuming, also called "defragmentation".
9+ single-page vacuuming, also called "defragmentation" or "pruning" .
1010
1111Note: there is a Glossary at the end of this document that may be helpful
1212for first-time readers.
@@ -31,12 +31,20 @@ corrupt index, in the form of entries pointing to tuple slots that by now
3131contain some unrelated content. In any case we would prefer to be able
3232to do vacuuming without invoking any user-written code.
3333
34- HOT solves this problem for a restricted but useful special case:
35- where a tuple is repeatedly updated in ways that do not change its
36- indexed columns. (Here, "indexed column" means any column referenced
34+ HOT solves this problem for two restricted but useful special cases:
35+
36+ First, where a tuple is repeatedly updated in ways that do not change
37+ its indexed columns. (Here, "indexed column" means any column referenced
3738at all in an index definition, including for example columns that are
3839tested in a partial-index predicate but are not stored in the index.)
3940
41+ Second, where the modified columns are only used in indexes that do not
42+ contain tuple IDs, but maintain summaries of the indexed data by block.
43+ As these indexes don't contain references to individual tuples, they
44+ can't remove tuple references in VACUUM, and thus don't need to get a new
45+ and unique reference to a tuple. These indexes still need to be notified
46+ of the new column data, but don't need a new HOT chain to be established.
47+
4048An additional property of HOT is that it reduces index size by avoiding
4149the creation of identically-keyed index entries. This improves search
4250speeds.
@@ -102,16 +110,16 @@ This is safe because no index entry points to line pointer 2. Subsequent
102110insertions into the page can now recycle both line pointer 2 and the
103111space formerly used by tuple 2.
104112
105- If an update changes any indexed column, or there is not room on the
106- same page for the new tuple, then the HOT chain ends: the last member
107- has a regular t_ctid link to the next version and is not marked
108- HEAP_HOT_UPDATED. (In principle we could continue a HOT chain across
109- pages, but this would destroy the desired property of being able to
110- reclaim space with just page-local manipulations. Anyway, we don't
111- want to have to chase through multiple heap pages to get from an index
112- entry to the desired tuple, so it seems better to create a new index
113- entry for the new tuple.) If further updates occur, the next version
114- could become the root of a new HOT chain.
113+ If an update changes any column indexed by a non-summarizing indexes, or
114+ if there is not room on the same page for the new tuple, then the HOT
115+ chain ends: the last member has a regular t_ctid link to the next version
116+ and is not marked HEAP_HOT_UPDATED. (In principle we could continue a
117+ HOT chain across pages, but this would destroy the desired property of
118+ being able to reclaim space with just page-local manipulations. Anyway,
119+ we don't want to have to chase through multiple heap pages to get from an
120+ index entry to the desired tuple, so it seems better to create a new
121+ index entry for the new tuple.) If further updates occur, the next
122+ version could become the root of a new HOT chain.
115123
116124Line pointer 1 has to remain as long as there is any non-dead member of
117125the chain on the page. When there is not, it is marked "dead".
@@ -125,15 +133,28 @@ Note: we can use a "dead" line pointer for any DELETEd tuple,
125133whether it was part of a HOT chain or not. This allows space reclamation
126134in advance of running VACUUM for plain DELETEs as well as HOT updates.
127135
128- The requirement for doing a HOT update is that none of the indexed
129- columns are changed. This is checked at execution time by comparing the
130- binary representation of the old and new values. We insist on bitwise
131- equality rather than using datatype-specific equality routines. The
132- main reason to avoid the latter is that there might be multiple notions
133- of equality for a datatype, and we don't know exactly which one is
134- relevant for the indexes at hand. We assume that bitwise equality
136+ The requirement for doing a HOT update is that indexes which point to
137+ the root line pointer (and thus need to be cleaned up by VACUUM when the
138+ tuple is dead) do not reference columns which are updated in that HOT
139+ chain. Summarizing indexes (such as BRIN) are assumed to have no
140+ references to individual tuples and thus are ignored when checking HOT
141+ applicability. The updated columns are checked at execution time by
142+ comparing the binary representation of the old and new values. We insist
143+ on bitwise equality rather than using datatype-specific equality routines.
144+ The main reason to avoid the latter is that there might be multiple
145+ notions of equality for a datatype, and we don't know exactly which one
146+ is relevant for the indexes at hand. We assume that bitwise equality
135147guarantees equality for all purposes.
136148
149+ If any columns that are included by non-summarizing indexes are updated,
150+ the HOT optimization is not applied, and the new tuple is inserted into
151+ all indexes of the table. If none of the updated columns are included in
152+ the table's indexes, the HOT optimization is applied and no indexes are
153+ updated. If instead the updated columns are only indexed by summarizing
154+ indexes, the HOT optimization is applied, but the update is propagated to
155+ all summarizing indexes. (Realistically, we only need to propagate the
156+ update to the indexes that contain the updated values, but that is yet to
157+ be implemented.)
137158
138159Abort Cases
139160-----------
0 commit comments