他のバージョンの文書 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

3.3. pg_am

pg_am にはインデックスアクセスメソッドの情報が格納されています。 システムにサポートされたそれぞれのインデックスアクセスメソッドに対しひとつの行が存在します。

Table 3-3. pg_am の列

名前参照先説明
amnamename アクセスメソッドの名前
amownerint4pg_shadow.usesysid所有者のユーザ ID (現時点では未使用)
amstrategiesint2 このアクセスメソッド用の演算子ストラテジの数
amsupportint2 このアクセスメソッド用のサポートルーチンの数
amorderstrategyint2 インデックスがソート順を提供しない場合はゼロ、その他の場合はソート順を記述する戦略演算子の戦略番号
amcanuniquebool AM が一意性インデックスをサポートするかどうか?
amcanmulticolbool AM が複数列インデックスをサポートするかどうか?
amindexnullsbool AM がインデックスエントリに NULL を許すかどうか?
amconcurrentbool AM が同時更新をサポートするかどうか?
amgettupleregprocpg_proc.oid"つぎの有効なタプル"関数
aminsertregprocpg_proc.oid"このタプルを挿入"関数
ambeginscanregprocpg_proc.oid"新規スキャンを開始"関数
amrescanregprocpg_proc.oid"このスキャンを再開"関数
amendscanregprocpg_proc.oid"このスキャンを終了"関数
ammarkposregprocpg_proc.oid"現在のスキャン位置を記録"関数
amrestrposregprocpg_proc.oid"記録したスキャン位置を復元"関数
ambuildregprocpg_proc.oid"新規インデックスをビルド"関数
ambulkdeleteregprocpg_proc.oidバルク削除関数
amcostestimateregprocpg_proc.oidインデックススキャンのコストの推測値

複数列をサポートするインデックス AM (amcanmulticolが真)は、1 列目に続く列のヌルのインデックス付けをサポートする必要があります。 これは、プランナが、インデックスを単に 1 列目に使用すれば問い合わせができると判断するためです。 たとえば、(a,b)上のインデックスと WHERE a = 4 という問い合わせについて考えてみましょう。 システムは、a = 4 である行のスキャンにインデックスを使用できると判断しますが、これは、b がヌルである行をインデックスが省略する場合には間違いとなります。 しかし、インデックス付けされた最初の列がヌルである行を省略するのは問題ありません。 (GiST は現在、そのように動作します。) amindexnulls は、インデックス AM が、ヌルの任意の組み合わせを含め、すべての行のインデックスとなるときにのみ真に設定される必要があります。