Index Access Method Functions
The index construction and maintenance functions that an index access method must provide 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 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.
The function must return a palloc'd struct containing statistics about
the new index.
bool aminsert (Relation indexRelation, Datum *values, bool *isnull, ItemPointer heap_tid, Relation heapRelation, IndexUniqueCheck checkUnique);
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 checkUnique indicates the type of uniqueness check to perform. This varies depending on whether the unique constraint is deferrable; see Section 51.5 for details. Normally the access method only needs the heapRelation parameter when performing uniqueness checking (since then it will have to look into the heap to verify tuple liveness).
The function's Boolean result value is significant only when checkUnique is UNIQUE_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
aminsert should just return without doing anything.
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-in callback function must 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.
It is OK to return NULL if no information needs to be passed on to
Because of limited maintenance_work_mem,
ambulkdelete might need to be called more than once when many
tuples are to be deleted. The stats argument is the result
of the previous call for this index (it is NULL for the first call within a
VACUUM operation). This allows the AM to accumulate statistics
across the whole operation. Typically,
modify and return the same struct if the passed stats is not
IndexBulkDeleteResult * amvacuumcleanup (IndexVacuumInfo *info, IndexBulkDeleteResult *stats);
Clean up after a VACUUM operation (zero or more
ambulkdelete 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
ambulkdelete call returned, or NULL if
ambulkdelete 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 update pg_class,
and will be reported by VACUUM if VERBOSE is given.
It is OK to return NULL if the index was not changed at all during the
VACUUM operation, but otherwise correct stats should
As of PostgreSQL 8.4,
amvacuumcleanup will also be called at completion of an
ANALYZE operation. In this case stats is always
NULL and any return value will be ignored. This case can be distinguished
by checking info->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.
void amcostestimate (PlannerInfo *root, IndexOptInfo *index, List *indexQuals, RelOptInfo *outer_rel, Cost *indexStartupCost, Cost *indexTotalCost, Selectivity *indexSelectivity, double *indexCorrelation);
Estimate the costs of an index scan. This function is described fully in Section 51.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 a text array containing entries of the form name=value. The function should construct a bytea value, which will be copied into the rd_options field of the index's relcache entry. The data contents of the bytea value are open for the access method to define; most of the standard access methods use struct StdRdOptions. When validate is true, the function should report a suitable error message if any of the options are unrecognized or have invalid values; when validate is false, invalid entries should be silently ignored. (validate is false when loading options already stored in pg_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.
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 51.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:
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 cases
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. On success,
must also set scan->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 by
amgettuple function need only be provided if the access
method supports "plain" index scans. If it doesn't, the
amgettuple field in its pg_am row must
be set to zero.
int64 amgetbitmap (IndexScanDesc scan, TIDBitmap *tbm);
Fetch all tuples in the given scan and add them to the caller-supplied
TIDBitmap (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,
indicate that rechecking of the scan conditions is required for specific
tuple IDs. This is analogous to the xs_recheck output parameter
amgettuple. 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.
amgettuple cannot be used in the same index scan; there
are other restrictions too when using
amgetbitmap, as explained
in Section 51.3.
amgetbitmap function need only be provided if the access
method supports "bitmap" index scans. If it doesn't, the
amgetbitmap field in its pg_am row must
be set to zero.
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.
By convention, the pg_proc entry for an 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.
The only exception is
amoptions, which should be correctly
declared as taking text and bool and returning
bytea. This provision allows client code to execute
amoptions to test validity of options settings.