60.2. Index Access Method Functions | ||||
---|---|---|---|---|
Prev | Up | Chapter 60. Index Access Method Interface Definition | Home | Next |
60.2. Index Access Method Functions#
The index construction and maintenance functions that an index access method must provide inIndexAmRoutine
are:
IndexBuildResult *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 theambuild
function will calltable_index_build_scan()
to scan the table for existing tuples and compute the keys that need to be inserted into the index. The function must return a palloc'd struct containing statistics about the new index. Theamcanbuildparallel
flag indicates whether the access method supports parallel index builds. When set totrue
, the system will attempt to allocate parallel workers for the build. Access methods supporting only non-parallel index builds should leave this flag set tofalse
.
voidambuildempty (Relation indexRelation);
Build an empty index, and write it to the initialization fork (INIT_FORKNUM
) of the given relation. This method is called only for unlogged indexes; the empty index written to the initialization fork will be copied over the main relation fork on each server restart.
boolaminsert (Relation indexRelation, Datum *values, bool *isnull, ItemPointer heap_tid, Relation heapRelation, IndexUniqueCheck checkUnique, bool indexUnchanged, IndexInfo *indexInfo);
Insert a new tuple into an existing index. Thevalues
andisnull
arrays give the key values to be indexed, andheap_tid
is the TID to be indexed. If the access method supports unique indexes (itsamcanunique
flag is true) thencheckUnique
indicates the type of uniqueness check to perform. This varies depending on whether the unique constraint is deferrable; seeSection 60.5 for details. Normally the access method only needs theheapRelation
parameter when performing uniqueness checking (since then it will have to look into the heap to verify tuple liveness).
TheindexUnchanged
Boolean value gives a hint about the nature of the tuple to be indexed. When it is true, the tuple is a duplicate of some existing tuple in the index. The new tuple is a logically unchanged successor MVCC tuple version. This happens when anUPDATE
takes place that does not modify any columns covered by the index, but nevertheless requires a new version in the index. The index AM may use this hint to decide to apply bottom-up index deletion in parts of the index where many versions of the same logical row accumulate. Note that updating a non-key column or a column that only appears in a partial index predicate does not affect the value ofindexUnchanged
. The core code determines each tuple'sindexUnchanged
value using a low overhead approach that allows both false positives and false negatives. Index AMs must not treatindexUnchanged
as an authoritative source of information about tuple visibility or versioning.
The function's Boolean result value is significant only whencheckUnique
isUNIQUE_CHECK_PARTIAL
. In this case a true result means the new entry is known unique, whereas false means it might be non-unique (and a deferred uniqueness check must be scheduled). For other cases a constant false result is recommended.
Some indexes might not index all tuples. If the tuple is not to be indexed,aminsert
should just return without doing anything.
If the index AM wishes to cache data across successive index insertions within an SQL statement, it can allocate space inindexInfo->ii_Context
and store a pointer to the data inindexInfo->ii_AmCache
(which will be NULL initially). If resources other than memory have to be released after index insertions,aminsertcleanup
may be provided, which will be called before the memory is released.
voidaminsertcleanup (Relation indexRelation, IndexInfo *indexInfo);
Clean up state that was maintained across successive inserts inindexInfo->ii_AmCache
. This is useful if the data requires additional cleanup steps (e.g., releasing pinned buffers), and simply releasing the memory is not sufficient.
IndexBulkDeleteResult *ambulkdelete (IndexVacuumInfo *info, IndexBulkDeleteResult *stats, 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-incallback
function must be called, in the stylecallback(
, 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. It is OK to return NULL if no information needs to be passed on toTID
, callback_state) returns boolamvacuumcleanup
.
Because of limitedmaintenance_work_mem
,ambulkdelete
might need to be called more than once when many tuples are to be deleted. Thestats
argument is the result of the previous call for this index (it is NULL for the first call within aVACUUM
operation). This allows the AM to accumulate statistics across the whole operation. Typically,ambulkdelete
will modify and return the same struct if the passedstats
is not null.
IndexBulkDeleteResult *amvacuumcleanup (IndexVacuumInfo *info, IndexBulkDeleteResult *stats);
Clean up after aVACUUM
operation (zero or moreambulkdelete
calls). This does not have to do anything beyond returning index statistics, but it might perform bulk cleanup such as reclaiming empty index pages.stats
is whatever the lastambulkdelete
call returned, or NULL ifambulkdelete
was not called because no tuples needed to be deleted. If the result is not NULL it must be a palloc'd struct. The statistics it contains will be used to updatepg_class
, and will be reported byVACUUM
ifVERBOSE
is given. It is OK to return NULL if the index was not changed at all during theVACUUM
operation, but otherwise correct stats should be returned.
amvacuumcleanup
will also be called at completion of anANALYZE
operation. In this casestats
is always NULL and any return value will be ignored. This case can be distinguished by checkinginfo->analyze_only
. It is recommended that the access method do nothing except post-insert cleanup in such a call, and that only in an autovacuum worker process.
boolamcanreturn (Relation indexRelation, int attno);
Check whether the index can supportindex-only scans on the given column, by returning the column's original indexed value. The attribute number is 1-based, i.e., the first column's attno is 1. Returns true if supported, else false. This function should always return true for included columns (if those are supported), since there's little point in an included column that can't be retrieved. If the access method does not support index-only scans at all, theamcanreturn
field in itsIndexAmRoutine
struct can be set to NULL.
voidamcostestimate (PlannerInfo *root, IndexPath *path, double loop_count, Cost *indexStartupCost, Cost *indexTotalCost, Selectivity *indexSelectivity, double *indexCorrelation, double *indexPages);
Estimate the costs of an index scan. This function is described fully inSection 60.6, below.
bytea *amoptions (ArrayType *reloptions, bool validate);
Parse and validate the reloptions array for an index. This is called only when a non-null reloptions array exists for the index.reloptions
is atext
array containing entries of the formname
=
value
. The function should construct abytea
value, which will be copied into therd_options
field of the index's relcache entry. The data contents of thebytea
value are open for the access method to define; most of the standard access methods use structStdRdOptions
. Whenvalidate
is true, the function should report a suitable error message if any of the options are unrecognized or have invalid values; whenvalidate
is false, invalid entries should be silently ignored. (validate
is false when loading options already stored inpg_catalog
; an invalid entry could only be found if the access method has changed its rules for options, and in that case ignoring obsolete entries is appropriate.) It is OK to return NULL if default behavior is wanted.
boolamproperty (Oid index_oid, int attno, IndexAMProperty prop, const char *propname, bool *res, bool *isnull);
Theamproperty
method allows index access methods to override the default behavior ofpg_index_column_has_property
and related functions. If the access method does not have any special behavior for index property inquiries, theamproperty
field in itsIndexAmRoutine
struct can be set to NULL. Otherwise, theamproperty
method will be called withindex_oid
andattno
both zero forpg_indexam_has_property
calls, or withindex_oid
valid andattno
zero forpg_index_has_property
calls, or withindex_oid
valid andattno
greater than zero forpg_index_column_has_property
calls.prop
is an enum value identifying the property being tested, whilepropname
is the original property name string. If the core code does not recognize the property name thenprop
isAMPROP_UNKNOWN
. Access methods can define custom property names by checkingpropname
for a match (usepg_strcasecmp
to match, for consistency with the core code); for names known to the core code, it's better to inspectprop
. If theamproperty
method returnstrue
then it has determined the property test result: it must set*res
to the Boolean value to return, or set*isnull
totrue
to return a NULL. (Both of the referenced variables are initialized tofalse
before the call.) If theamproperty
method returnsfalse
then the core code will proceed with its normal logic for determining the property test result.
Access methods that support ordering operators should implementAMPROP_DISTANCE_ORDERABLE
property testing, as the core code does not know how to do that and will return NULL. It may also be advantageous to implementAMPROP_RETURNABLE
testing, if that can be done more cheaply than by opening the index and callingamcanreturn
, which is the core code's default behavior. The default behavior should be satisfactory for all other standard properties.
char *ambuildphasename (int64 phasenum);
Return the textual name of the given build phase number. The phase numbers are those reported during an index build via thepgstat_progress_update_param
interface. The phase names are then exposed in thepg_stat_progress_create_index
view.
boolamvalidate (Oid opclassoid);
Validate the catalog entries for the specified operator class, so far as the access method can reasonably do that. For example, this might include testing that all required support functions are provided. Theamvalidate
function must return false if the opclass is invalid. Problems should be reported withereport
messages, typically atINFO
level.
voidamadjustmembers (Oid opfamilyoid, Oid opclassoid, List *operators, List *functions);
Validate proposed new operator and function members of an operator family, so far as the access method can reasonably do that, and set their dependency types if the default is not satisfactory. This is called duringCREATE OPERATOR CLASS
and duringALTER OPERATOR FAMILY ADD
; in the latter caseopclassoid
isInvalidOid
. TheList
arguments are lists ofOpFamilyMember
structs. Tests done by this function will typically be a subset of those performed byamvalidate
, sinceamadjustmembers
cannot assume that it is seeing a complete set of members. For example, it would be reasonable to check the signature of a support function, but not to check whether all required support functions are provided. Any problems can be reported by throwing an error. The dependency-related fields of theOpFamilyMember
structs are initialized by the core code to create hard dependencies on the opclass if this isCREATE OPERATOR CLASS
, or soft dependencies on the opfamily if this isALTER OPERATOR FAMILY ADD
.amadjustmembers
can adjust these fields if some other behavior is more appropriate. For example, GIN, GiST, and SP-GiST always set operator members to have soft dependencies on the opfamily, since the connection between an operator and an opclass is relatively weak in these index types; so it is reasonable to allow operator members to be added and removed freely. Optional support functions are typically also given soft dependencies, so that they can be removed if necessary.
The purpose of an index, of course, is to support scans for tuples matching an indexableWHERE
condition, often called aqualifier orscan key. The semantics of index scanning are described more fully inSection 60.3, below. An index access method can support“plain” index scans,“bitmap” index scans, or both. The scan-related functions that an index access method must or may provide are:
IndexScanDescambeginscan (Relation indexRelation, int nkeys, int norderbys);
Prepare for an index scan. Thenkeys
andnorderbys
parameters indicate the number of quals and ordering operators that will be used in the scan; these may be useful for space allocation purposes. Note that the actual values of the scan keys aren't provided yet. The result must be a palloc'd struct. For implementation reasons the index access methodmust create this struct by callingRelationGetIndexScan()
. In most casesambeginscan
does little beyond making that call and perhaps acquiring locks; the interesting parts of index-scan startup are inamrescan
.
voidamrescan (IndexScanDesc scan, ScanKey keys, int nkeys, ScanKey orderbys, int norderbys);
Start or restart an index scan, possibly with new scan keys. (To restart using previously-passed keys, NULL is passed forkeys
and/ororderbys
.) Note that it is not allowed for the number of keys or order-by operators to be larger than what was passed toambeginscan
. 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.
boolamgettuple (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 thescan
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. On success,amgettuple
must also setscan->xs_recheck
to true or false. False means it is certain that the index entry matches the scan keys. True means this is not certain, and the conditions represented by the scan keys must be rechecked against the heap tuple after fetching it. This provision supports“lossy” index operators. Note that rechecking will extend only to the scan conditions; a partial index predicate (if any) is never rechecked byamgettuple
callers.
If the index supportsindex-only scans (i.e.,amcanreturn
returns true for any of its columns), then on success the AM must also checkscan->xs_want_itup
, and if that is true it must return the originally indexed data for the index entry. Columns for whichamcanreturn
returns false can be returned as nulls. The data can be returned in the form of anIndexTuple
pointer stored atscan->xs_itup
, with tuple descriptorscan->xs_itupdesc
; or in the form of aHeapTuple
pointer stored atscan->xs_hitup
, with tuple descriptorscan->xs_hitupdesc
. (The latter format should be used when reconstructing data that might possibly not fit into anIndexTuple
.) In either case, management of the data referenced by the pointer is the access method's responsibility. The data must remain good at least until the nextamgettuple
,amrescan
, oramendscan
call for the scan.
Theamgettuple
function need only be provided if the access method supports“plain” index scans. If it doesn't, theamgettuple
field in itsIndexAmRoutine
struct must be set to NULL.
int64amgetbitmap (IndexScanDesc scan, TIDBitmap *tbm);
Fetch all tuples in the given scan and add them to the caller-suppliedTIDBitmap
(that is, OR the set of tuple IDs into whatever set is already in the bitmap). The number of tuples fetched is returned (this might be just an approximate count, for instance some AMs do not detect duplicates). While inserting tuple IDs into the bitmap,amgetbitmap
can indicate that rechecking of the scan conditions is required for specific tuple IDs. This is analogous to thexs_recheck
output parameter ofamgettuple
. Note: in the current implementation, support for this feature is conflated with support for lossy storage of the bitmap itself, and therefore callers recheck both the scan conditions and the partial index predicate (if any) for recheckable tuples. That might not always be true, however.amgetbitmap
andamgettuple
cannot be used in the same index scan; there are other restrictions too when usingamgetbitmap
, as explained inSection 60.3.
Theamgetbitmap
function need only be provided if the access method supports“bitmap” index scans. If it doesn't, theamgetbitmap
field in itsIndexAmRoutine
struct must be set to NULL.
voidamendscan (IndexScanDesc scan);
End a scan and release resources. Thescan
struct itself should not be freed, but any locks or pins taken internally by the access method must be released, as well as any other memory allocated byambeginscan
and other scan-related functions.
voidammarkpos (IndexScanDesc scan);
Mark current scan position. The access method need only support one remembered scan position per scan.
Theammarkpos
function need only be provided if the access method supports ordered scans. If it doesn't, theammarkpos
field in itsIndexAmRoutine
struct may be set to NULL.
voidamrestrpos (IndexScanDesc scan);
Restore the scan to the most recently marked position.
Theamrestrpos
function need only be provided if the access method supports ordered scans. If it doesn't, theamrestrpos
field in itsIndexAmRoutine
struct may be set to NULL.
In addition to supporting ordinary index scans, some types of index may wish to supportparallel index scans, which allow multiple backends to cooperate in performing an index scan. The index access method should arrange things so that each cooperating process returns a subset of the tuples that would be performed by an ordinary, non-parallel index scan, but in such a way that the union of those subsets is equal to the set of tuples that would be returned by an ordinary, non-parallel index scan. Furthermore, while there need not be any global ordering of tuples returned by a parallel scan, the ordering of that subset of tuples returned within each cooperating backend must match the requested ordering. The following functions may be implemented to support parallel index scans:
Sizeamestimateparallelscan (int nkeys, int norderbys);
Estimate and return the number of bytes of dynamic shared memory which the access method will be needed to perform a parallel scan. (This number is in addition to, not in lieu of, the amount of space needed for AM-independent data inParallelIndexScanDescData
.)
Thenkeys
andnorderbys
parameters indicate the number of quals and ordering operators that will be used in the scan; the same values will be passed toamrescan
. Note that the actual values of the scan keys aren't provided yet.
It is not necessary to implement this function for access methods which do not support parallel scans or for which the number of additional bytes of storage required is zero.
voidaminitparallelscan (void *target);
This function will be called to initialize dynamic shared memory at the beginning of a parallel scan.target
will point to at least the number of bytes previously returned byamestimateparallelscan
, and this function may use that amount of space to store whatever data it wishes.
It is not necessary to implement this function for access methods which do not support parallel scans or in cases where the shared memory space required needs no initialization.
voidamparallelrescan (IndexScanDesc scan);
This function, if implemented, will be called when a parallel index scan must be restarted. It should reset any shared state set up byaminitparallelscan
such that the scan will be restarted from the beginning.