他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

第60章 インデックスアクセスメソッドのインタフェース定義

目次

60.1. インデックスの基本的API構造
60.2. インデックスアクセスメソッド関数
60.3. インデックススキャン
60.4. インデックスのロック処理に関する検討
60.5. インデックス一意性検査
60.6. インデックスコスト推定関数

本章は、PostgreSQLのコアシステムと個々のインデックス種類を管理するインデックスアクセスメソッドとの間のインタフェースを定義します。 コアシステムはインデックスの仕様のみを把握しています。 したがって、追加コードを記述することで完全に新しいインデックス種類を開発することができます。

PostgreSQLのインデックスはすべて、技術的には補助的なインデックスとして知られるものです。 つまり、インデックスは対象となるテーブルファイルとは物理的に分かれています。 各インデックスは独自の物理的なリレーションとして格納され、また、pg_classカタログ内の項目として記述されます。 インデックスの内容は完全にそのインデックスアクセスメソッドの制御下にあります。 実際、すべてのインデックスアクセスメソッドは、通常の格納マネージャとバッファマネージャを使用してインデックスの内容にアクセスできるように、インデックスを標準サイズのページに分割します。 (既存のすべてのインデックスアクセスメソッドではさらに、66.6で説明する標準ページレイアウトを使用し、そのほとんどは同じ書式をインデックスタプルヘッダに使用します。 しかし、これはアクセスメソッドに強制されていることではありません。)

インデックスは効率的にあるデータキー値を、インデックスの親テーブル内の行バージョン(タプル)のタプル識別子言い換えるとTIDに関連付けます。 TIDは、ブロック番号、ブロック内の項目番号(66.6を参照)から構成されます。 これは、特定の行バージョンをテーブルから取り出すのに十分な情報です。 MVCCでは1つの論理的な行に複数の現在のバージョンがあることを、インデックスが直接意識することはありません。 インデックスでは、各タプルは、独自にインデックス項目を持たなければならない独立したオブジェクトです。 したがって、行を更新すると、キーの値が変わっていなかってとしても、その行に対してまったく新しいインデックス項目が作成されます。 (HOTタプルはこの説明の例外ですが、インデックスはこれらにも関与しません。) (バキューム実行によって)無効タプル自身が回収された時に、無効タプルに対するインデックス項目は回収されます。