|PostgreSQL 8.1.23 Documentation|
|Prev||Fast Backward||Chapter 48. Index Access Method Interface Definition||Fast Forward||Next|
The index construction and maintenance functions that an index access method must provide are:
void ambuild (Relation heapRelation, Relation indexRelation, IndexInfo *indexInfo);
Build a new index. The index relation has been physically
created, but is empty. It must be filled in with whatever fixed
data the access method requires, plus entries for all tuples
already existing in the table. Ordinarily the
ambuild function will call
IndexBuildHeapScan() to scan the table for
existing tuples and compute the keys that need to be inserted
into the index.
bool aminsert (Relation indexRelation, Datum *values, bool *isnull, ItemPointer heap_tid, Relation heapRelation, bool check_uniqueness);
Insert a new tuple into an existing index. The values and isnull arrays give the key values to be indexed, and heap_tid is the TID to be indexed. If the access method supports unique indexes (its pg_am.amcanunique flag is true) then check_uniqueness may be true, in which case the access method must verify that there is no conflicting row; this is the only situation in which the access method normally needs the heapRelation parameter. See Section 48.5 for details. The result is TRUE if an index entry was inserted, FALSE if not. (A FALSE result does not denote an error condition, but is used for cases such as an index AM refusing to index a NULL.)
IndexBulkDeleteResult * ambulkdelete (Relation indexRelation, IndexBulkDeleteCallback callback, void *callback_state);
Delete tuple(s) from the index. This is a "bulk delete" operation that is intended to be implemented by scanning the whole index and checking each entry to see if it should be deleted. The passed-in callback function may be called, in the style callback(TID, callback_state) returns bool, to determine whether any particular index entry, as identified by its referenced TID, is to be deleted. Must return either NULL or a palloc'd struct containing statistics about the effects of the deletion operation.
IndexBulkDeleteResult * amvacuumcleanup (Relation indexRelation, IndexVacuumCleanupInfo *info, IndexBulkDeleteResult *stats);
Clean up after a VACUUM operation
(one or more
An index access method does not have to provide this function (if
so, the entry in pg_am must be zero).
If it is provided, it is typically used for bulk cleanup such as
reclaiming empty index pages. info
provides some additional arguments such as a message level for
statistical reports, and stats is
whatever the last
replace or modify this struct before returning it. If the result
is not NULL it must be a palloc'd struct. The statistics it
contains will be reported by VACUUM if
VERBOSE is given.
The purpose of an index, of course, is to support scans for tuples matching an indexable WHERE condition, often called a qualifier or scan key. The semantics of index scanning are described more fully in Section 48.3, below. The scan-related functions that an index access method must provide are:
IndexScanDesc ambeginscan (Relation indexRelation, int nkeys, ScanKey key);
Begin a new scan. The key array (of
length nkeys) describes the scan key(s)
for the index scan. The result must be a palloc'd struct. For
implementation reasons the index access method must create this struct by calling
RelationGetIndexScan(). In most
ambeginscan itself does
little beyond making that call; the interesting parts of
index-scan startup are in
boolean amgettuple (IndexScanDesc scan, ScanDirection direction);
Fetch the next tuple in the given scan, moving in the given direction (forward or backward in the index). Returns TRUE if a tuple was obtained, FALSE if no matching tuples remain. In the TRUE case the tuple TID is stored into the scan structure. Note that "success" means only that the index contains an entry that matches the scan keys, not that the tuple necessarily still exists in the heap or will pass the caller's snapshot test.
boolean amgetmulti (IndexScanDesc scan, ItemPointer tids, int32 max_tids, int32 *returned_tids);
Fetch multiple tuples in the given scan. Returns TRUE if the
scan should continue, FALSE if no matching tuples remain.
tids points to a caller-supplied array
of max_tids ItemPointerData records, which the call fills
with TIDs of matching tuples. *returned_tids is set to the number of TIDs
actually returned. This can be less than max_tids, or even zero, even when the return value
is TRUE. (This provision allows the access method to choose the
most efficient stopping points in its scan, for example index
amgettuple cannot be used in the
same index scan; there are other restrictions too when using
amgetmulti, as explained in
void amrescan (IndexScanDesc scan, ScanKey key);
Restart the given scan, possibly with new scan keys (to
continue using the old keys, NULL is passed for key). Note that it is not possible for the number
of keys to be changed. In practice the restart feature is used
when a new outer tuple is selected by a nested-loop join and so a
new key comparison value is needed, but the scan key structure
remains the same. This function is also called by
RelationGetIndexScan(), so it is used for
initial setup of an index scan as well as rescanning.
void amendscan (IndexScanDesc scan);
End a scan and release resources. The scan struct itself should not be freed, but any locks or pins taken internally by the access method must be released.
void ammarkpos (IndexScanDesc scan);
Mark current scan position. The access method need only support one remembered scan position per scan.
void amrestrpos (IndexScanDesc scan);
Restore the scan to the most recently marked position.
void amcostestimate (PlannerInfo *root, IndexOptInfo *index, List *indexQuals, Cost *indexStartupCost, Cost *indexTotalCost, Selectivity *indexSelectivity, double *indexCorrelation);
Estimate the costs of an index scan. This function is described fully in Section 48.6, below.
By convention, the pg_proc entry for any index access method function should show the correct number of arguments, but declare them all as type internal (since most of the arguments have types that are not known to SQL, and we don't want users calling the functions directly anyway). The return type is declared as void, internal, or boolean as appropriate.
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.