database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-05 07:21:24 +03:00
Code Activity

Standardize ItemIdData terminology.

Browse Source 
The term "item pointer" should not be used to refer to ItemIdData
variables, since that is needlessly ambiguous.  Only
ItemPointerData/ItemPointer variables should be called item pointers.

To fix, establish the convention that ItemIdData variables should always
be referred to either as "item identifiers" or "line pointers".  The
term "item identifier" already predominates in docs and translatable
messages, and so should be the preferred alternative there.

Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=E4ndQ2--8ew@mail.gmail.com
This commit is contained in:
Peter Geoghegan
2019-05-13 15:53:39 -07:00
parent 08ca9d7fec
commit ae7291acbc
14 changed files with 52 additions and 73 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/access/heap/README.HOT
View File

@ -149,8 +149,8 @@ the descendant heap-only tuple. It is conceivable that someone prunes
the heap-only tuple before that, and even conceivable that the line pointer
is re-used for another purpose. Therefore, when following a HOT chain,
it is always necessary to be prepared for the possibility that the
linked-to item pointer is unused, dead, or redirected; and if it is a
normal item pointer, we still have to check that XMIN of the tuple matches
linked-to line pointer is unused, dead, or redirected; and if it is a
normal line pointer, we still have to check that XMIN of the tuple matches
the XMAX of the tuple we left. Otherwise we should assume that we have
come to the end of the HOT chain. Note that this sort of XMIN/XMAX
matching is required when following ordinary update chains anyway.
@ -171,14 +171,14 @@ bit: there can be at most one visible tuple in the chain, so we can stop
when we find it. This rule does not work for non-MVCC snapshots, though.)
Sequential scans do not need to pay attention to the HOT links because
they scan every item pointer on the page anyway. The same goes for a
they scan every line pointer on the page anyway. The same goes for a
bitmap heap scan with a lossy bitmap.
Pruning
-------
HOT pruning means updating item pointers so that HOT chains are
HOT pruning means updating line pointers so that HOT chains are
reduced in length, by collapsing out line pointers for intermediate dead
tuples. Although this makes those line pointers available for re-use,
it does not immediately make the space occupied by their tuples available.
@ -271,7 +271,7 @@ physical tuple by eliminating an intermediate heap-only tuple or
replacing a physical root tuple by a redirect pointer, a decrement in
the table's number of dead tuples is reported to pgstats, which may
postpone autovacuuming. Note that we do not count replacing a root tuple
by a DEAD item pointer as decrementing n_dead_tuples; we still want
by a DEAD line pointer as decrementing n_dead_tuples; we still want
autovacuum to run to clean up the index entries and DEAD item.
This area probably needs further work ...

4
src/backend/access/heap/heapam.c
View File

@ -7163,7 +7163,7 @@ log_heap_clean(Relation reln, Buffer buffer,
* arrays need not be stored too. Note that even if all three arrays are
* empty, we want to expose the buffer as a candidate for whole-page
* storage, since this record type implies a defragmentation operation
* even if no item pointers changed state.
* even if no line pointers changed state.
*/
if (nredirected > 0)
XLogRegisterBufData(0, (char *) redirected,
@ -7724,7 +7724,7 @@ heap_xlog_clean(XLogReaderState *record)
nunused = (end - nowunused);
Assert(nunused >= 0);
/* Update all item pointers per the record, and repair fragmentation */
/* Update all line pointers per the record, and repair fragmentation */
heap_page_prune_execute(buffer,
redirected, nredirected,
nowdead, ndead,

2
src/backend/access/heap/heapam_handler.c
View File

@ -2162,7 +2162,7 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
else
{
/*
* Bitmap is lossy, so we must examine each item pointer on the page.
* Bitmap is lossy, so we must examine each line pointer on the page.
* But we can ignore HOT chains, since we'll check each tuple anyway.
*/
Page dp = (Page) BufferGetPage(buffer);

10
src/backend/access/heap/pruneheap.c
View File

@ -324,7 +324,7 @@ heap_page_prune(Relation relation, Buffer buffer, TransactionId OldestXmin,
/*
* Prune specified item pointer or a HOT chain originating at that item.
* Prune specified line pointer or a HOT chain originating at line pointer.
*
* If the item is an index-referenced tuple (i.e. not a heap-only tuple),
* the HOT chain is pruned by removing all DEAD tuples at the start of the HOT
@ -454,7 +454,7 @@ heap_prune_chain(Relation relation, Buffer buffer, OffsetNumber rootoffnum,
}
/*
* Likewise, a dead item pointer can't be part of the chain. (We
* Likewise, a dead line pointer can't be part of the chain. (We
* already eliminated the case of dead root tuple outside this
* function.)
*/
@ -630,7 +630,7 @@ heap_prune_record_prunable(PruneState *prstate, TransactionId xid)
prstate->new_prune_xid = xid;
}
/* Record item pointer to be redirected */
/* Record line pointer to be redirected */
static void
heap_prune_record_redirect(PruneState *prstate,
OffsetNumber offnum, OffsetNumber rdoffnum)
@ -645,7 +645,7 @@ heap_prune_record_redirect(PruneState *prstate,
prstate->marked[rdoffnum] = true;
}
/* Record item pointer to be marked dead */
/* Record line pointer to be marked dead */
static void
heap_prune_record_dead(PruneState *prstate, OffsetNumber offnum)
{
@ -656,7 +656,7 @@ heap_prune_record_dead(PruneState *prstate, OffsetNumber offnum)
prstate->marked[offnum] = true;
}
/* Record item pointer to be marked unused */
/* Record line pointer to be marked unused */
static void
heap_prune_record_unused(PruneState *prstate, OffsetNumber offnum)
{

6
src/backend/access/heap/vacuumlazy.c
View File

@ -509,7 +509,7 @@ lazy_scan_heap(Relation onerel, VacuumParams *params, LVRelStats *vacrelstats,
live_tuples, /* live tuples (reltuples estimate) */
tups_vacuumed, /* tuples cleaned up by vacuum */
nkeep, /* dead-but-not-removable tuples */
nunused; /* unused item pointers */
nunused; /* unused line pointers */
IndexBulkDeleteResult **indstats;
int i;
PGRUsage ru0;
@ -1017,7 +1017,7 @@ lazy_scan_heap(Relation onerel, VacuumParams *params, LVRelStats *vacrelstats,
ItemPointerSet(&(tuple.t_self), blkno, offnum);
/*
* DEAD item pointers are to be vacuumed normally; but we don't
* DEAD line pointers are to be vacuumed normally; but we don't
* count them in tups_vacuumed, else we'd be double-counting (at
* least in the common case where heap_page_prune() just freed up
* a non-HOT tuple).
@ -1483,7 +1483,7 @@ lazy_scan_heap(Relation onerel, VacuumParams *params, LVRelStats *vacrelstats,
appendStringInfo(&buf,
_("%.0f dead row versions cannot be removed yet, oldest xmin: %u\n"),
nkeep, OldestXmin);
appendStringInfo(&buf, _("There were %.0f unused item pointers.\n"),
appendStringInfo(&buf, _("There were %.0f unused item identifiers.\n"),
nunused);
appendStringInfo(&buf, ngettext("Skipped %u page due to buffer pins, ",
"Skipped %u pages due to buffer pins, ",