Movatterモバイル変換

Each index access method is described by a row in thepg_am system catalog (seeSection 49.3). The principal contents of apg_am row are references topg_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, thepg_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 deletingpg_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 moreoperator families andoperator classes defined inpg_opfamily,pg_opclass,pg_amop, andpg_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 inSection 35.14, which is prerequisite material for reading this chapter.

An individual index is defined by apg_class entry that describes it as a physical relation, plus apg_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 inpg_index. Both of these catalog entries can be accessed as part of theRelation data structure that is passed to all operations on the index.

Some of the flag columns ofpg_am have nonobvious implications. The requirements ofamcanunique are discussed inSection 58.5. Theamcanmulticol flag asserts that the access method supports multicolumn indexes, whileamoptionalkey asserts that it allows scans where no indexable restriction clause is given for the first index column. Whenamcanmulticol is false,amoptionalkey essentially says whether the access method supports full-index scans without any restriction clause. Access methods that support multiple index columnsmust 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 settingamoptionalkey false. One reason that an index AM might setamoptionalkey 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 haveamoptionalkey 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 columnsmust 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 withWHERE a = 4. The system will assume the index can be used to scan for rows witha = 4, which is wrong if the index omits rows whereb 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 setamsearchnulls, indicating that it supportsIS NULL andIS NOT NULL clauses as search conditions.