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.
void ambuildempty (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 tables; the empty index written to the initialization fork will be copied over the main relation fork on each server restart.
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 54.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 indexed,
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_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,
ambulkdelete will modify and return
the same struct if the passed stats is
IndexBulkDeleteResult * amvacuumcleanup (IndexVacuumInfo *info, IndexBulkDeleteResult *stats);
Clean up after a VACUUM operation
(zero or more
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
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 be returned.
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
bool amcanreturn (Relation indexRelation);
Check whether the index can support index-only scans by returning the indexed column values for an index entry in the form of an IndexTuple. Return TRUE if so, else FALSE. If the index AM can never support index-only scans (an example is hash, which stores only the hash values not the original data), it is sufficient to set its amcanreturn field to zero in pg_am.
void amcostestimate (PlannerInfo *root, IndexPath *path, double loop_count, Cost *indexStartupCost, Cost *indexTotalCost, Selectivity *indexSelectivity, double *indexCorrelation);
Estimate the costs of an index scan. This function is described fully in Section 54.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 54.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, int norderbys);
Prepare for an index scan. The nkeys
and norderbys 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 method must create this struct by calling
RelationGetIndexScan(). In most
ambeginscan does little
beyond making that call and perhaps acquiring locks; the
interesting parts of index-scan startup are in
void amrescan (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 for
keys and/or orderbys.) Note that it is not allowed for the
number of keys or order-by operators to be larger than what was
ambeginscan. 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.
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.
amgettuple 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
If the index supports index-only scans (i.e.,
amcanreturn returns TRUE for it), then on
success the AM must also check scan->xs_want_itup, and if that is true it must
return the original indexed data for the index entry, in the form
of an IndexTuple pointer stored at
scan->xs_itup, with tuple descriptor
scan->xs_itupdesc. (Management of the
data referenced by the pointer is the access method's
responsibility. The data must remain good at least until the next
amendscan call for the scan.)
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,
amgetbitmap can indicate that
rechecking of the scan conditions is required for specific tuple
IDs. This is analogous to the xs_recheck
output parameter of
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 54.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 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
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
Please use this form to add your own comments regarding your experience with particular features of PostgreSQL, clarifications of the documentation, or hints for other users. Please note, this is not a support forum, and your IP address will be logged. If you have a question or need help, please see the faq, try a mailing list, or join us on IRC. Note that submissions containing URLs or other keywords commonly found in 'spam' comments may be silently discarded. Please contact the webmaster if you think this is happening to you in error.
Proceed to the comment form.