Index Access Method Functions

PostgreSQL 8.4.2 Documentation
Prev | Fast Backward | Chapter 50. Index Access Method Interface Definition | Fast Forward | Next

# 50.2. 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,
              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` might 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 50.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 method 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(`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 `amvacuumcleanup`.

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 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 might 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.

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 50.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 50.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 `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. On success, `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 `amgettuple` callers.

The `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 `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. `amgetbitmap` and `amgettuple` cannot be used in the same index scan; there are other restrictions too when using `amgetbitmap`, as explained in Section 50.3.

The `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.

Prev | Home | Next
Catalog Entries for Indexes | Up | Index Scanning