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, 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 49.5, “Index Uniqueness Checks” 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 (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(
,
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
TID
, callback_state) returns boolamvacuumcleanup
.
Because of limited maintenance_work_mem
,
ambulkdelete
may 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 not
null.
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 may perform bulk cleanup
such as reclaiming empty index pages. stats
is whatever the
last 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
be returned.
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 49.6, “Index Cost Estimation Functions”, 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, but the standard access methods currently all 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 49.3, “Index Scanning”,
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 cases
ambeginscan
itself does little beyond making that call;
the interesting parts of index-scan startup are in amrescan
.
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 page boundaries.) amgetmulti
and
amgettuple
cannot be used in the same index scan; there
are other restrictions too when using amgetmulti
, as explained
in Section 49.3, “Index Scanning”.
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.