Each index access method is described by a row in the
<link linkend="catalog-pg-am"><structname>pg_am</structname></link>
system catalog. The <structname>pg_am</structname> entry
specifies a name and a <firstterm>handler function</firstterm> for the index
access method. These entries can be created and deleted using the
<xref linkend="sql-create-access-method"/> and
<xref linkend="sql-drop-access-method"/> SQL commands.
各インデックスメソッドはpg_amシステムカタログの行で説明されます。
pg_amエントリはインデックスアクセスメソッドの名前とハンドラ関数を指定します。
これらのエントリはSQLコマンドCREATE ACCESS METHODとDROP ACCESS METHODを使って、作成および削除することができます。
An index access method handler function must be declared to accept a
single argument of type <type>internal</type> and to return the
pseudo-type <type>index_am_handler</type>. The argument is a dummy value that
simply serves to prevent handler functions from being called directly from
SQL commands. The result of the function must be a palloc'd struct of
type <structname>IndexAmRoutine</structname>, which contains everything
that the core code needs to know to make use of the index access method.
The <structname>IndexAmRoutine</structname> struct, also called the access
method's <firstterm>API struct</firstterm>, includes fields specifying assorted
fixed properties of the access method, such as whether it can support
multicolumn indexes. More importantly, it contains pointers to support
functions for the access method, which do all of the real work to access
indexes. These support functions are plain C functions and are not
visible or callable at the SQL level. The support functions are described
in <xref linkend="index-functions"/>.
インデックスメソッドのハンドラ関数は、internal型の引数を1つ取り、疑似型index_am_handlerを返すものとして宣言しなければなりません。
引数は単にハンドラ関数がSQLコマンドから直接呼び出されるのを防ぐためのダミーの値です。
関数の結果は型IndexAmRoutineのpallocされた構造体でなければならず、そこにはインデックスアクセスメソッドを使用するためにコアコードが知っている必要のあるすべてのことが含まれています。
IndexAmRoutine構造体は、アクセスメソッドのAPI構造体とも呼ばれ、複数列のインデックスをサポートするかどうかなどといった、アクセスメソッドに関する様々な既定の属性を指定するフィールドが含まれます。
さらに重要なことに、この構造体にはアクセスメソッドのサポート関数へのポインタが含まれ、これによってインデックスにアクセスするためのすべての実際の処理が行われます。
これらのサポート関数は単なるCの関数で、SQLレベルでは見ることも呼び出すこともできません。
サポート関数は64.2で説明されています。
The structure <structname>IndexAmRoutine</structname> is defined thus:
構造体IndexAmRoutineは以下のように定義されています。
typedef struct IndexAmRoutine
{
NodeTag type;
/*
* Total number of strategies (operators) by which we can traverse/search
* this AM. Zero if AM does not have a fixed set of strategy assignments.
*/
uint16 amstrategies;
/* total number of support functions that this AM uses */
uint16 amsupport;
/* opclass options support function number or 0 */
uint16 amoptsprocnum;
/* does AM support ORDER BY indexed column's value? */
bool amcanorder;
/* does AM support ORDER BY result of an operator on indexed column? */
bool amcanorderbyop;
/* does AM support backward scanning? */
bool amcanbackward;
/* does AM support UNIQUE indexes? */
bool amcanunique;
/* does AM support multi-column indexes? */
bool amcanmulticol;
/* does AM require scans to have a constraint on the first index column? */
bool amoptionalkey;
/* does AM handle ScalarArrayOpExpr quals? */
bool amsearcharray;
/* does AM handle IS NULL/IS NOT NULL quals? */
bool amsearchnulls;
/* can index storage data type differ from column data type? */
bool amstorage;
/* can an index of this type be clustered on? */
bool amclusterable;
/* does AM handle predicate locks? */
bool ampredlocks;
/* does AM support parallel scan? */
bool amcanparallel;
/* does AM support columns included with clause INCLUDE? */
bool amcaninclude;
/* does AM use maintenance_work_mem? */
bool amusemaintenanceworkmem;
/* does AM summarize tuples, with at least all tuples in the block
* summarized in one summary */
bool amsummarizing;
/* OR of parallel vacuum flags */
uint8 amparallelvacuumoptions;
/* type of data stored in index, or InvalidOid if variable */
Oid amkeytype;
/* interface functions */
ambuild_function ambuild;
ambuildempty_function ambuildempty;
aminsert_function aminsert;
ambulkdelete_function ambulkdelete;
amvacuumcleanup_function amvacuumcleanup;
amcanreturn_function amcanreturn; /* can be NULL */
amcostestimate_function amcostestimate;
amoptions_function amoptions;
amproperty_function amproperty; /* can be NULL */
ambuildphasename_function ambuildphasename; /* can be NULL */
amvalidate_function amvalidate;
amadjustmembers_function amadjustmembers; /* can be NULL */
ambeginscan_function ambeginscan;
amrescan_function amrescan;
amgettuple_function amgettuple; /* can be NULL */
amgetbitmap_function amgetbitmap; /* can be NULL */
amendscan_function amendscan;
ammarkpos_function ammarkpos; /* can be NULL */
amrestrpos_function amrestrpos; /* can be NULL */
/* interface functions to support parallel index scans */
amestimateparallelscan_function amestimateparallelscan; /* can be NULL */
aminitparallelscan_function aminitparallelscan; /* can be NULL */
amparallelrescan_function amparallelrescan; /* can be NULL */
} IndexAmRoutine;
To be useful, an index access method must also have one or more
<firstterm>operator families</firstterm> and
<firstterm>operator classes</firstterm> defined in
<link linkend="catalog-pg-opfamily"><structname>pg_opfamily</structname></link>,
<link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link>,
<link linkend="catalog-pg-amop"><structname>pg_amop</structname></link>, and
<link linkend="catalog-pg-amproc"><structname>pg_amproc</structname></link>.
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 <xref linkend="xindex"/>, which is prerequisite material for reading
this chapter.
使い易くするために、インデックスアクセスメソッドはまた、pg_opfamily、pg_opclass、pg_amopおよびpg_amproc内で定義される、複数の演算子族と演算子クラスを持ちます。
これらの項目により、プランナは、このアクセスメソッドのインデックスがどのような問い合わせ条件に対して使用できるかを決定することができます。
演算子族と演算子クラスについては、38.16で説明します。
これは本章を読む上で必要となる資料です。
An individual index is defined by a
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>
entry that describes it as a physical relation, plus a
<link linkend="catalog-pg-index"><structname>pg_index</structname></link>
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
<structname>pg_index</structname>. Both of these catalog entries can be
accessed as part of the <structname>Relation</structname> data structure that is
passed to all operations on the index.
個々のインデックスは、インデックスを物理的なリレーションとして記述するpg_class項目と、インデックスの論理的な内容、つまり、インデックスが持つインデックス列の集合とその列の意味を、関連する演算子クラスで再現されたものとして表すpg_index項目とで定義されます。
インデックス列（キー値）は、背後のテーブルの単純な列、あるいは、テーブル行に対する式とすることができます。
通常、インデックスアクセスメソッドはインデックスキー値が何を表すかについて考慮しません。
（常に計算済みのキー値として扱われます。）
しかし、pg_index内の演算子クラスの情報を深く考慮します。
この両方のカタログ項目は、インデックスに対するすべての操作に渡されるRelationデータ構造の一部としてアクセスすることができます。
Some of the flag fields of <structname>IndexAmRoutine</structname> have nonobvious
implications. The requirements of <structfield>amcanunique</structfield>
are discussed in <xref linkend="index-unique-checks"/>.
The <structfield>amcanmulticol</structfield> flag asserts that the
access method supports multi-key-column indexes, while
<structfield>amoptionalkey</structfield> asserts that it allows scans
where no indexable restriction clause is given for the first index column.
When <structfield>amcanmulticol</structfield> is false,
<structfield>amoptionalkey</structfield> essentially says whether the
access method supports full-index scans without any restriction clause.
Access methods that support multiple index columns <emphasis>must</emphasis>
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
<structfield>amoptionalkey</structfield> false.
One reason that an index AM might set
<structfield>amoptionalkey</structfield> 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 <structfield>amoptionalkey</structfield> 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 <emphasis>must</emphasis>
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
<literal>WHERE a = 4</literal>. The system will assume the index can be
used to scan for rows with <literal>a = 4</literal>, which is wrong if the
index omits rows where <literal>b</literal> 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
<structfield>amsearchnulls</structfield>, indicating that it supports
<literal>IS NULL</literal> and <literal>IS NOT NULL</literal> clauses as search
conditions.
IndexAmRoutineのフラグフィールドの中には、意味がわかりにくいものがあります。
amcanuniqueの必要条件は64.5で説明されています。
amcanmulticolフラグはアクセスメソッドが複数キー列に対するインデックスをサポートすることを表し、amoptionalkeyは、インデックス可能な制限句が最初のインデックス列に指定されていないスキャンを許可することを表します。
amcanmulticolが偽の場合、amoptionalkeyは基本的に、アクセスメソッドが制限句なしで完全なインデックススキャンをサポートするかどうかを表します。
複数列に対するインデックスをサポートするアクセスメソッドは、最初の列以降のすべてまたは一部の列に関する制限がなくてもスキャンをサポートしなければなりません。
しかし、最初のインデックス列にいくつかの制限を要求することは認められています。
これは、amoptionalkeyを偽に設定することで通知されます。
インデックスアクセスメソッドがamoptionalkeyを偽にする１つの理由は、NULLをインデックス付けしない場合です。
ほとんどのインデックス可能な演算子は厳密で、NULL値の入力に対して真を返すことができませんので、NULLに対してインデックス項目を格納しないことは一見魅力的です。
これはインデックススキャンによって何も返しません。
しかし、最初のインデックス列に対する制限がないインデックススキャンでは、この引数は失敗します。
プランナがこうしたスキャンキーをまったく持たないインデックスを使用することを決定する可能性がありますので、実際これは、amoptionalkeyが真のインデックスはNULLインデックスを持たなければならないことを意味します。
関連する制限として、プランナはこれらの列を制限しない問い合わせでインデックスを使用できることを前提とするため、複数のインデックス列をサポートするインデックスアクセスメソッドは1番目の後の列でNULL値のインデックスをサポートしなければならないということがあります。
例えば、(a,b)に対するインデックスに、WHERE a = 4という条件で問い合わせを行うことを考えてみます。
システムは、このインデックスをa = 4を持つ行をスキャンすることに使用できるものと仮定します。
これはもし、bがNULLの場合の行をインデックスが省略する場合は間違っています。
しかし、最初のインデックス列がNULLの場合に行を省略することは問題ありません
また、NULLをインデックス付けするインデックスアクセスメソッドはamsearchnullsを設定する可能性があります。
これは検索条件としてIS NULLおよびIS NOT NULL句をサポートすることを示します。
The <structfield>amcaninclude</structfield> flag indicates whether the
access method supports <quote>included</quote> columns, that is it can
store (without processing) additional columns beyond the key column(s).
The requirements of the preceding paragraph apply only to the key
columns. In particular, the combination
of <structfield>amcanmulticol</structfield>=<literal>false</literal>
and <structfield>amcaninclude</structfield>=<literal>true</literal> is
sensible: it means that there can only be one key column, but there can
also be included column(s). Also, included columns must be allowed to be
null, independently of <structfield>amoptionalkey</structfield>.
amcanincludeフラグは、このアクセスメソッドが（処理することなく）キー列以外の追加の列を格納することができる「included」列をサポートしているかどうかを示します。
前段落の要件はキー列にのみ適用されます。
とりわけ、amcanmulticol=falseとamcaninclude=trueの組み合わせは実用的です。
これは単一のキー列だけが存在しつつも、include列が存在することができることを示しています。
また、amoptionalkeyとは独立して、include列はNULLにすることができなければなりません。
The <structfield>amsummarizing</structfield> flag indicates whether the
access method summarizes the indexed tuples, with summarizing granularity
of at least per block.
Access methods that do not point to individual tuples, but to block ranges
(like <acronym>BRIN</acronym>), may allow the <acronym>HOT</acronym> optimization
to continue. This does not apply to attributes referenced in index
predicates, an update of such an attribute always disables <acronym>HOT</acronym>.
amsummarizingフラグは、このアクセスメソッドがインデックス付きタプルを要約するかどうかを示します。
要約の粒度は少なくともブロック以上です。
個々のタプルを指すのではなく、ブロック範囲を指すアクセスメソッド（BRINのような）は、HOT最適化を継続できる可能性があります。
これは、インデックス述語で参照される属性には適用されません。
そのような属性の更新は常にHOTが無効になります。