Each index access method is described by a row in the
pg_am system catalog (see Section 47.3). The principal contents of
a pg_am row are references to
pg_proc entries that identify the index
access functions supplied by the access method. The APIs for
these functions are defined later in this chapter. In addition,
the pg_am row specifies a few fixed
properties of the access method, such as whether it can support
multicolumn indexes. There is not currently any special support
for creating or deleting pg_am
entries; anyone able to write a new access method is expected to
be competent to insert an appropriate row for themselves.

To be useful, an index access method must also have one or
more operator families and operator classes defined in pg_opfamily, pg_opclass, pg_amop,
and pg_amproc. These entries allow the planner
to determine what kinds of query qualifications can be used with
indexes of this access method. Operator families and classes are
described in Section 35.14, which is
prerequisite material for reading this chapter.

An individual index is defined by a pg_class
entry that describes it as a physical relation, plus a pg_index
entry that shows the logical content of the index — that is, the
set of index columns it has and the semantics of those columns,
as captured by the associated operator classes. The index columns
(key values) can be either simple columns of the underlying table
or expressions over the table rows. The index access method
normally has no interest in where the index key values come from
(it is always handed precomputed key values) but it will be very
interested in the operator class information in pg_index. Both of these catalog entries can be
accessed as part of the Relation data
structure that is passed to all operations on the index.

Some of the flag columns of pg_am
have nonobvious implications. The requirements of amcanunique are discussed in Section 54.5. The amcanmulticol flag asserts that the access
method supports multicolumn indexes, while amoptionalkey asserts that it allows scans
where no indexable restriction clause is given for the first
index column. When amcanmulticol is
false, amoptionalkey essentially
says whether the access method supports full-index scans without
any restriction clause. Access methods that support multiple
index columns must
support scans that omit restrictions on any or all of the columns
after the first; however they are permitted to require some
restriction to appear for the first index column, and this is
signaled by setting amoptionalkey
false. One reason that an index AM might set amoptionalkey false is if it doesn't index
null values. Since most indexable operators are strict and hence
cannot return true for null inputs, it is at first sight
attractive to not store index entries for null values: they could
never be returned by an index scan anyway. However, this argument
fails when an index scan has no restriction clause for a given
index column. In practice this means that indexes that have
amoptionalkey true must index nulls,
since the planner might decide to use such an index with no scan
keys at all. A related restriction is that an index access method
that supports multiple index columns must support indexing null values
in columns after the first, because the planner will assume the
index can be used for queries that do not restrict these columns.
For example, consider an index on (a,b) and a query with
WHERE a = 4. The system will assume the
index can be used to scan for rows with a =
4, which is wrong if the index omits rows where b is null. It is, however, OK to omit rows where
the first indexed column is null. An index access method that
does index nulls may also set amsearchnulls, indicating that it supports
IS NULL and IS NOT
NULL clauses as search conditions.