This chapter defines the interface between the core <productname>PostgreSQL</productname> system and <firstterm>index access methods</firstterm>, which manage individual index types. The core system knows nothing about indexes beyond what is specified here, so it is possible to develop entirely new index types by writing add-on code. 本章は、PostgreSQLのコアシステムと個々のインデックス種類を管理するインデックスアクセスメソッドとの間のインタフェースを定義します。 コアシステムはインデックスの仕様のみを把握しています。 したがって、追加コードを記述することで完全に新しいインデックス種類を開発することができます。

All indexes in <productname>PostgreSQL</productname> are what are known technically as <firstterm>secondary indexes</firstterm>; that is, the index is physically separate from the table file that it describes. Each index is stored as its own physical <firstterm>relation</firstterm> and so is described by an entry in the <structname>pg_class</structname> catalog. The contents of an index are entirely under the control of its index access method. In practice, all index access methods divide indexes into standard-size pages so that they can use the regular storage manager and buffer manager to access the index contents. (All the existing index access methods furthermore use the standard page layout described in <xref linkend="storage-page-layout"/>, and most use the same format for index tuple headers; but these decisions are not forced on an access method.) PostgreSQLのインデックスはすべて、技術的には補助的なインデックスとして知られるものです。 つまり、インデックスは対象となるテーブルファイルとは物理的に分かれています。 各インデックスは独自の物理的なリレーションとして格納され、また、pg_classカタログ内の項目として記述されます。 インデックスの内容は完全にそのインデックスアクセスメソッドの制御下にあります。 実際、すべてのインデックスアクセスメソッドは、通常の格納マネージャとバッファマネージャを使用してインデックスの内容にアクセスできるように、インデックスを標準サイズのページに分割します。 （既存のすべてのインデックスアクセスメソッドではさらに、73.6で説明する標準ページレイアウトを使用し、そのほとんどは同じ書式をインデックスタプルヘッダに使用します。 しかし、これはアクセスメソッドに強制されていることではありません。）

An index is effectively a mapping from some data key values to <firstterm>tuple identifiers</firstterm>, or <acronym>TIDs</acronym>, of row versions (tuples) in the index's parent table. A TID consists of a block number and an item number within that block (see <xref linkend="storage-page-layout"/>). This is sufficient information to fetch a particular row version from the table. Indexes are not directly aware that under MVCC, there might be multiple extant versions of the same logical row; to an index, each tuple is an independent object that needs its own index entry. Thus, an update of a row always creates all-new index entries for the row, even if the key values did not change. (<link linkend="storage-hot">HOT tuples</link> are an exception to this statement; but indexes do not deal with those, either.) Index entries for dead tuples are reclaimed (by vacuuming) when the dead tuples themselves are reclaimed. インデックスは効率的にあるデータキー値を、インデックスの親テーブル内の行バージョン（タプル）のタプル識別子言い換えるとTIDに関連付けます。 TIDは、ブロック番号、ブロック内の項目番号（73.6を参照）から構成されます。 これは、特定の行バージョンをテーブルから取り出すのに十分な情報です。 MVCCでは1つの論理的な行に複数の現在のバージョンがあることを、インデックスが直接意識することはありません。 インデックスでは、各タプルは、独自にインデックス項目を持たなければならない独立したオブジェクトです。 したがって、行を更新すると、キーの値が変わっていなかってとしても、その行に対してまったく新しいインデックス項目が作成されます。 （HOTタプルはこの説明の例外ですが、インデックスはこれらにも関与しません。） （バキューム実行によって）無効タプル自身が回収された時に、無効タプルに対するインデックス項目は回収されます。