Fix comments related to table AMs
Incorrect function names were referenced. As this fixes some portions of tableam.h, that is mentioned in the docs as something to look at when implementing a table AM, backpatch down to 12 where this has been introduced. Author: Hironobu Suzuki Discussion: https://postgr.es/m/8fe6d672-28dd-3f1d-7aed-ac2f6d599d3f@interdb.jp Backpatch-through: 12
This commit is contained in:
parent
0734dbc450
commit
9678c08184
@ -1639,9 +1639,9 @@ heap_get_latest_tid(TableScanDesc sscan,
|
||||
TransactionId priorXmax;
|
||||
|
||||
/*
|
||||
* table_get_latest_tid verified that the passed in tid is valid. Assume
|
||||
* that t_ctid links are valid however - there shouldn't be invalid ones
|
||||
* in the table.
|
||||
* table_tuple_get_latest_tid() verified that the passed in tid is valid.
|
||||
* Assume that t_ctid links are valid however - there shouldn't be invalid
|
||||
* ones in the table.
|
||||
*/
|
||||
Assert(ItemPointerIsValid(tid));
|
||||
|
||||
|
@ -1003,12 +1003,12 @@ table_index_fetch_end(struct IndexFetchTableData *scan)
|
||||
* that tuple. Index AMs can use that to avoid returning that tid in future
|
||||
* searches.
|
||||
*
|
||||
* The difference between this function and table_fetch_row_version is that
|
||||
* this function returns the currently visible version of a row if the AM
|
||||
* supports storing multiple row versions reachable via a single index entry
|
||||
* (like heap's HOT). Whereas table_fetch_row_version only evaluates the
|
||||
* tuple exactly at `tid`. Outside of index entry ->table tuple lookups,
|
||||
* table_tuple_fetch_row_version is what's usually needed.
|
||||
* The difference between this function and table_tuple_fetch_row_version()
|
||||
* is that this function returns the currently visible version of a row if
|
||||
* the AM supports storing multiple row versions reachable via a single index
|
||||
* entry (like heap's HOT). Whereas table_tuple_fetch_row_version() only
|
||||
* evaluates the tuple exactly at `tid`. Outside of index entry ->table tuple
|
||||
* lookups, table_tuple_fetch_row_version() is what's usually needed.
|
||||
*/
|
||||
static inline bool
|
||||
table_index_fetch_tuple(struct IndexFetchTableData *scan,
|
||||
@ -1062,8 +1062,9 @@ table_tuple_fetch_row_version(Relation rel,
|
||||
/*
|
||||
* Verify that `tid` is a potentially valid tuple identifier. That doesn't
|
||||
* mean that the pointed to row needs to exist or be visible, but that
|
||||
* attempting to fetch the row (e.g. with table_get_latest_tid() or
|
||||
* table_fetch_row_version()) should not error out if called with that tid.
|
||||
* attempting to fetch the row (e.g. with table_tuple_get_latest_tid() or
|
||||
* table_tuple_fetch_row_version()) should not error out if called with that
|
||||
* tid.
|
||||
*
|
||||
* `scan` needs to have been started via table_beginscan().
|
||||
*/
|
||||
@ -1192,8 +1193,8 @@ table_tuple_complete_speculative(Relation rel, TupleTableSlot *slot,
|
||||
/*
|
||||
* Insert multiple tuples into a table.
|
||||
*
|
||||
* This is like table_insert(), but inserts multiple tuples in one
|
||||
* operation. That's often faster than calling table_insert() in a loop,
|
||||
* This is like table_tuple_insert(), but inserts multiple tuples in one
|
||||
* operation. That's often faster than calling table_tuple_insert() in a loop,
|
||||
* because e.g. the AM can reduce WAL logging and page locking overhead.
|
||||
*
|
||||
* Except for taking `nslots` tuples as input, and an array of TupleTableSlots
|
||||
|
Loading…
x
Reference in New Issue
Block a user