The index construction and maintenance functions that an index access
method must provide in <structname>IndexAmRoutine</structname> are:
インデックスアクセスメソッドがIndexAmRoutine
で提供しなければならない、インデックス構築および保守関数を以下に示します。
IndexBuildResult * ambuild (Relation heapRelation, Relation indexRelation, IndexInfo *indexInfo);
Build a new index. The index relation has been physically created,
but is empty. It must be filled in with whatever fixed data the
access method requires, plus entries for all tuples already existing
in the table. Ordinarily the <function>ambuild</function> function will call
<function>table_index_build_scan()</function> to scan the table for existing tuples
and compute the keys that need to be inserted into the index.
The function must return a palloc'd struct containing statistics about
the new index.
The <structfield>amcanbuildparallel</structfield> flag indicates whether
the access method supports parallel index builds. When set to <literal>true</literal>,
the system will attempt to allocate parallel workers for the build.
Access methods supporting only non-parallel index builds should leave
this flag set to <literal>false</literal>.
《マッチ度[57.243816]》新しいインデックスを構築します。
空のインデックスリレーションが物理的に作成されます。
これは、アクセスメソッドが必要とする何らかの固定データと、テーブル内に既に存在するすべてのタプルに対応する項目が書き込まれなければなりません。
通常、ambuild
関数はtable_index_build_scan()
を呼び出し、既存のタプルをテーブルからスキャンし、インデックスに挿入しなければならないキーを計算します。
この関数は、新しいインデックスに関する統計情報を含むpallocされた構造体を返さなければなりません。
《機械翻訳》新しいインデックスのビルド。
インデックスリレーションは物理的に作成されていますが、空です。
アクセスメソッドが必要とする固定されたデータ、プラスにすでに存在するすべてのタプルのテーブルエントリを入力する必要があります。
通常、ambuild
関数は、既存のタプルのテーブルを呼び出しtable_index_build_scan()
し、インデックスに挿入する必要があるキーを計算します。
スキャン関数は、新しいインデックスに関する統計処理を含むpallocされた構造体を結果する必要があります。
amcanbuildparallel
フラグは、アクセス方法がパラレルインデックス構築をサポートするかどうかを示します。
true
に設定すると、システムはビルドに並行ワーカーを割り当てようとします。
アクセスメソッド以外のインデックスビルドのみをサポートするパラレルは、このフラグセットをfalse
に残す必要があります。
void ambuildempty (Relation indexRelation);
Build an empty index, and write it to the initialization fork (<symbol>INIT_FORKNUM</symbol>)
of the given relation. This method is called only for unlogged indexes; the
empty index written to the initialization fork will be copied over the main
relation fork on each server restart.
空のインデックスを構築し、それを指定されたリレーションの初期フォーク(INIT_FORKNUM
)に書き出します。
このメソッドはログを取らないインデックスに対してのみ呼び出されます。
初期フォークに書き出された空のインデックスは、サーバの再起動の度に主リレーションフォークにコピーされます。
bool aminsert (Relation indexRelation, Datum *values, bool *isnull, ItemPointer heap_tid, Relation heapRelation, IndexUniqueCheck checkUnique, bool indexUnchanged, IndexInfo *indexInfo);
Insert a new tuple into an existing index. The <literal>values</literal> and
<literal>isnull</literal> arrays give the key values to be indexed, and
<literal>heap_tid</literal> is the TID to be indexed.
If the access method supports unique indexes (its
<structfield>amcanunique</structfield> flag is true) then
<literal>checkUnique</literal> indicates the type of uniqueness check to
perform. This varies depending on whether the unique constraint is
deferrable; see <xref linkend="index-unique-checks"/> for details.
Normally the access method only needs the <literal>heapRelation</literal>
parameter when performing uniqueness checking (since then it will have to
look into the heap to verify tuple liveness).
既存のインデックスに新しいタプルを挿入します。
values
配列とisnull
配列がインデックスされるキー値を提供するもので、heap_tid
がインデックスされるTIDです。
アクセスメソッドが一意なインデックスをサポートする場合(そのamcanunique
が真の場合)、checkUnique
は実行する一意性検査の種類を示します。
これは一意性制約が遅延可能か否かによって変わります。
62.5を参照してください。
通常アクセスメソッドは、一意性検査を行う時にheapRelation
パラメータのみを必要とします
(タプルの有効性を検証するためにヒープ内を検索しなければなりません)。
The <literal>indexUnchanged</literal> Boolean value gives a hint
about the nature of the tuple to be indexed. When it is true,
the tuple is a duplicate of some existing tuple in the index. The
new tuple is a logically unchanged successor MVCC tuple version. This
happens when an <command>UPDATE</command> takes place that does not
modify any columns covered by the index, but nevertheless requires a
new version in the index. The index AM may use this hint to decide
to apply bottom-up index deletion in parts of the index where many
versions of the same logical row accumulate. Note that updating a non-key
column or a column that only appears in a partial index predicate does not
affect the value of <literal>indexUnchanged</literal>. The core code
determines each tuple's <literal>indexUnchanged</literal> value using a low
overhead approach that allows both false positives and false negatives.
Index AMs must not treat <literal>indexUnchanged</literal> as an
authoritative source of information about tuple visibility or versioning.
indexUnchanged
真偽値はインデックス付されるタプルの性質に関するヒントを与えます。
真なら、そのタプルは既存のインデックス中のタプルと重複しています。
新しいタプルは論理的に変わっていない後継であるMVCCタプルバージョンです。
これはUPDATE
の実行によりインデックス対象のどの列も変更されず、それにもかかわらずインデックスにおいて新しいバージョンを要求する場合に起こります。
インデックスAMは、同じ論理的な行の多くのバージョンが蓄積されるときに、インデックスのある部分にボトムアップインデックス削除を適用するかどうかを決定するためにこのヒントを使うことができます。
非キー列や部分インデックス述語にのみ現れる列を更新してもindexUnchanged
の値には影響がないことに留意してください。
コアコードは、偽陽性と偽陰性の両方を許容する低オーバーヘッドのアプローチを使用して、各タプルのindexUnchanged
値を決定します。
インデックスAMは、indexUnchanged
を、タプルの可視性やバージョニングに関する信頼できる情報源として扱ってはいけません。
The function's Boolean result value is significant only when
<literal>checkUnique</literal> is <literal>UNIQUE_CHECK_PARTIAL</literal>.
In this case a true result means the new entry is known unique, whereas
false means it might be non-unique (and a deferred uniqueness check must
be scheduled). For other cases a constant false result is recommended.
checkUnique
がUNIQUE_CHECK_PARTIAL
の場合、関数の論理型の結果値で十分です。
この場合、真の結果は新しい項目は一意であることが確認されたことを、一方偽の結果は一意でない可能性があること(遅延一意性検査を予定しなければならないこと)を意味します。
他の場合では、一定の偽という結果が推奨されます。
Some indexes might not index all tuples. If the tuple is not to be
indexed, <function>aminsert</function> should just return without doing anything.
一部のインデックスではすべてのタプルをインデックス付けしない可能性があります。
タプルがインデックス付けされない場合、aminsert
は何も行わずに戻らなければなりません。
If the index AM wishes to cache data across successive index insertions
within an SQL statement, it can allocate space
in <literal>indexInfo->ii_Context</literal> and store a pointer to the
data in <literal>indexInfo->ii_AmCache</literal> (which will be NULL
initially). If resources other than memory have to be released after
index insertions, <function>aminsertcleanup</function> may be provided,
which will be called before the memory is released.
《マッチ度[57.986871]》SQL文の中で、インデックスAMがインデックスへの連続的な挿入をまたがってデータをキャッシュすることが望ましい場合は、indexInfo->ii_Context
にメモリを確保し、そのデータへのポインタをindexInfo->ii_AmCache
(初期値はNULLです)に格納することができます。
《機械翻訳》インデックスAMがインデックスステートメント内の連続するSQL挿入にわたってデータをキャッシュしたい場合は、indexInfo->ii_Context
にスペースを割り当て、indexInfo->ii_AmCache
にデータへのポインタを保存できます(最初はnullになります)。
インデックス挿入の後にメモリ以外のリソースを解放する必要がある場合は、メモリが解放される前と呼ばれるaminsertcleanup
が提供されることがあります。
void aminsertcleanup (Relation indexRelation, IndexInfo *indexInfo);
Clean up state that was maintained across successive inserts in
<literal>indexInfo->ii_AmCache</literal>. This is useful if the data
requires additional cleanup steps (e.g., releasing pinned buffers), and
simply releasing the memory is not sufficient.
《機械翻訳》indexInfo->ii_AmCache
への連続した挿入で維持されていた状態をクリーンアップします。
これは、データに追加のクリーンアップステップが必要で(固定されたバッファを解放するなど)、メモリを解放するだけでは不十分な場合に便利です。
IndexBulkDeleteResult * ambulkdelete (IndexVacuumInfo *info, IndexBulkDeleteResult *stats, IndexBulkDeleteCallback callback, void *callback_state);
Delete tuple(s) from the index. This is a <quote>bulk delete</quote> operation
that is intended to be implemented by scanning the whole index and checking
each entry to see if it should be deleted.
The passed-in <literal>callback</literal> function must be called, in the style
<literal>callback(<replaceable>TID</replaceable>, callback_state) returns bool</literal>,
to determine whether any particular index entry, as identified by its
referenced TID, is to be deleted. Must return either NULL or a palloc'd
struct containing statistics about the effects of the deletion operation.
It is OK to return NULL if no information needs to be passed on to
<function>amvacuumcleanup</function>.
インデックスからタプル(複数可)を削除します。
これは「一括削除」操作を行いますが、インデックス全体をスキャンし、各項目に対して削除すべきかどうか検査を行うように実装されることが想定されています。
渡されるcallback
関数は、callback(
という形で、参照用TIDで識別されるインデックス項目を削除すべきかどうか決定するために呼び出さなければなりません。
NULLまたはpallocした削除操作の影響に関する統計情報を含む構造体を返さなければなりません。
TID
, callback_state) returns boolamvacuumcleanup
に渡さなければならない情報がなければ、NULLを返しても問題ありません。
Because of limited <varname>maintenance_work_mem</varname>,
<function>ambulkdelete</function> might need to be called more than once when many
tuples are to be deleted. The <literal>stats</literal> argument is the result
of the previous call for this index (it is NULL for the first call within a
<command>VACUUM</command> operation). This allows the AM to accumulate statistics
across the whole operation. Typically, <function>ambulkdelete</function> will
modify and return the same struct if the passed <literal>stats</literal> is not
null.
maintenance_work_mem
の制限により、多くのタプルが削除される時、ambulkdelete
を複数回呼び出す必要があるかもしれません。
stats
引数は、このインデックスに対する前回の呼び出し結果です。
(VACUUM
操作における最初の呼び出しではこれはNULLです。)
これにより、アクセスメソッドは操作全体に跨った統計情報を計算することができます。
典型的に、渡されたstats
がNULLでない場合、ambulkdelete
は同じ構造体を変更し、返します。
IndexBulkDeleteResult * amvacuumcleanup (IndexVacuumInfo *info, IndexBulkDeleteResult *stats);
Clean up after a <command>VACUUM</command> operation (zero or more
<function>ambulkdelete</function> calls). This does not have to do anything
beyond returning index statistics, but it might perform bulk cleanup
such as reclaiming empty index pages. <literal>stats</literal> is whatever the
last <function>ambulkdelete</function> call returned, or NULL if
<function>ambulkdelete</function> was not called because no tuples needed to be
deleted. If the result is not NULL it must be a palloc'd struct.
The statistics it contains will be used to update <structname>pg_class</structname>,
and will be reported by <command>VACUUM</command> if <literal>VERBOSE</literal> is given.
It is OK to return NULL if the index was not changed at all during the
<command>VACUUM</command> operation, but otherwise correct stats should
be returned.
VACUUM
操作(0回以上のambulkdelete
呼び出し)後の整理を行います。
これは、インデックス統計情報を返す以上の処理を行う必要はありません。
しかし、空のインデックスページの回収などの一括整理を行う可能性があります。
stats
は最後のambulkdelete
呼び出しが返したものです。
削除する必要があるタプルが存在しなかったためにambulkdelete
が呼び出されなかった場合はNULLとなります。
結果はNULLでなければ、pallocされた構造体でなければなりません。
含まれる統計情報はpg_class
を更新するために使用され、また、VERBOSE
が指定されたVACUUM
によって報告されます。
VACUUM
操作の間にインデックスがまったく変わらなかった場合はNULLを返しても問題ありません。
しかし、そうでなければ正しい統計情報を返さなければなりません。
<function>amvacuumcleanup</function> will also be called at completion of an
<command>ANALYZE</command> operation. In this case <literal>stats</literal> is always
NULL and any return value will be ignored. This case can be distinguished
by checking <literal>info->analyze_only</literal>. It is recommended
that the access method do nothing except post-insert cleanup in such a
call, and that only in an autovacuum worker process.
amvacuumcleanup
もANALYZE
操作の完了時点にも呼び出されます。
この場合、stats
は常にNULLで、戻り値はまったく無視されます。
この事象はinfo->analyze_only
を検査することで識別されます。
アクセスメソッドがそのような呼び出しで挿入後の整理以外何もしないように、そしてそれは自動バキュームワーカープロセスのみであるようにすることを推奨します。
bool amcanreturn (Relation indexRelation, int attno);
Check whether the index can support <link
linkend="indexes-index-only-scans"><firstterm>index-only scans</firstterm></link> on
the given column, by returning the column's original indexed value.
The attribute number is 1-based, i.e., the first column's attno is 1.
Returns true if supported, else false.
This function should always return true for included columns
(if those are supported), since there's little point in an included
column that can't be retrieved.
If the access method does not support index-only scans at all,
the <structfield>amcanreturn</structfield> field in its <structname>IndexAmRoutine</structname>
struct can be set to NULL.
列のインデックスされた元の値を返すことにより、そのインデックスが指定された列でインデックスオンリースキャンをサポート可能かどうかを判断します。
属性番号は1始まり、すなわち最初の列のattnoは1です。
インデックスオンリースキャンがサポートされている場合は真が返され、サポートされていない場合は偽が返ります。
取得できない列がinclude列である意味はないので、この関数は(サポートされていれば)include列に対しては常に真を返すでしょう。
アクセスメソッドがインデックスオンリースキャンをサポートしていない場合、IndexAmRoutine
構造体のamcanreturn
フィールドをNULLにセットすることができます。
void amcostestimate (PlannerInfo *root, IndexPath *path, double loop_count, Cost *indexStartupCost, Cost *indexTotalCost, Selectivity *indexSelectivity, double *indexCorrelation, double *indexPages);
Estimate the costs of an index scan. This function is described fully in <xref linkend="index-cost-estimation"/>, below. インデックススキャンのコストを推定します。 この関数については後述の62.6で説明します。
bytea * amoptions (ArrayType *reloptions, bool validate);
Parse and validate the reloptions array for an index. This is called only
when a non-null reloptions array exists for the index.
<parameter>reloptions</parameter> is a <type>text</type> array containing entries of the
form <replaceable>name</replaceable><literal>=</literal><replaceable>value</replaceable>.
The function should construct a <type>bytea</type> value, which will be copied
into the <structfield>rd_options</structfield> field of the index's relcache entry.
The data contents of the <type>bytea</type> value are open for the access
method to define; most of the standard access methods use struct
<structname>StdRdOptions</structname>.
When <parameter>validate</parameter> is true, the function should report a suitable
error message if any of the options are unrecognized or have invalid
values; when <parameter>validate</parameter> is false, invalid entries should be
silently ignored. (<parameter>validate</parameter> is false when loading options
already stored in <structname>pg_catalog</structname>; an invalid entry could only
be found if the access method has changed its rules for options, and in
that case ignoring obsolete entries is appropriate.)
It is OK to return NULL if default behavior is wanted.
インデックス用のreloptionsの解析と検証を行います。
インデックスに非NULLのreloptions配列が存在する場合にのみ呼び出されます。
reloptions
は、name
=
value
形式の項目からなる、text
型の配列です。
この関数はbytea
型の値を生成しなければならず、この値はインデックスのrelcache項目のrd_options
フィールドにコピーされます。
bytea
型の値の内容はアクセスメソッドが独自に定義できるように開放されています。
標準のアクセスメソッドのほとんどはすべてStdRdOptions
構造体を使用します。
validate
が真の場合、何らかのオプションが認識できなかった場合や無効な値が存在した場合、この関数は適切なエラーメッセージを報告しなければなりません。
validate
が偽の場合、無効な項目は単に無視されます。
(読み込みオプションが既にpg_catalog
に格納されている場合validate
は偽です。
アクセスメソッドがそのオプション用の規則を変更した場合にのみ、無効な項目が検出されます。
そして、その場合、古い項目を無視することが適切です。)
デフォルトの動作を行わせたい場合はNULLを返しても問題ありません。
bool amproperty (Oid index_oid, int attno, IndexAMProperty prop, const char *propname, bool *res, bool *isnull);
The <function>amproperty</function> method allows index access methods to override
the default behavior of <function>pg_index_column_has_property</function>
and related functions.
If the access method does not have any special behavior for index property
inquiries, the <structfield>amproperty</structfield> field in
its <structname>IndexAmRoutine</structname> struct can be set to NULL.
Otherwise, the <function>amproperty</function> method will be called with
<parameter>index_oid</parameter> and <parameter>attno</parameter> both zero for
<function>pg_indexam_has_property</function> calls,
or with <parameter>index_oid</parameter> valid and <parameter>attno</parameter> zero for
<function>pg_index_has_property</function> calls,
or with <parameter>index_oid</parameter> valid and <parameter>attno</parameter> greater than
zero for <function>pg_index_column_has_property</function> calls.
<parameter>prop</parameter> is an enum value identifying the property being tested,
while <parameter>propname</parameter> is the original property name string.
If the core code does not recognize the property name
then <parameter>prop</parameter> is <literal>AMPROP_UNKNOWN</literal>.
Access methods can define custom property names by
checking <parameter>propname</parameter> for a match (use <function>pg_strcasecmp</function>
to match, for consistency with the core code); for names known to the core
code, it's better to inspect <parameter>prop</parameter>.
If the <structfield>amproperty</structfield> method returns <literal>true</literal> then
it has determined the property test result: it must set <literal>*res</literal>
to the Boolean value to return, or set <literal>*isnull</literal>
to <literal>true</literal> to return a NULL. (Both of the referenced variables
are initialized to <literal>false</literal> before the call.)
If the <structfield>amproperty</structfield> method returns <literal>false</literal> then
the core code will proceed with its normal logic for determining the
property test result.
amproperty
メソッドにより、インデックスメソッドはpg_index_column_has_property
および関連する関数のデフォルトの動作を上書きすることができます。
インデックスアクセスメソッドがインデックスの属性の問い合わせについて特別な動作をしないのなら、IndexAmRoutine
構造体のamproperty
フィールドはNULLにすることができます。
そうでなければ、amproperty
はpg_indexam_has_property
の呼び出しに対し、index_oid
とattno
をいずれもゼロにして、pg_index_has_property
の呼び出しに対してindex_oid
が有効、attno
がゼロで、あるいはpg_index_column_has_property
の呼び出しに対してindex_oid
が有効、attno
が1以上で呼び出されます。
prop
は検査対象の属性を指定する列挙型の値、propname
は元の属性の名称の文字列です。
コアのコードが属性名を認識しない場合、prop
はAMPROP_UNKNOWN
になります。
アクセスメソッドはカスタム属性名を定義して、マッチするものをpropname
で確認する(コアコードとの一貫性のため、pg_strcasecmp
を使ってください)ことができます。
コアコードに既知の名前については、prop
を検査する方が良いです。
amproperty
メソッドがtrue
を返すなら、それは属性検査の結果が決定したということで、*res
を返すべき論理値にセットするか、NULLを返すために*isnull
をtrue
にセットするかしなければなりません。
(どちらの参照変数も、呼び出しの前にfalse
に初期化されます。)
amproperty
メソッドがfalse
を返すなら、コアコードは属性検査の結果を決定するために、通常の手続きを進めます。
Access methods that support ordering operators should
implement <literal>AMPROP_DISTANCE_ORDERABLE</literal> property testing, as the
core code does not know how to do that and will return NULL. It may
also be advantageous to implement <literal>AMPROP_RETURNABLE</literal> testing,
if that can be done more cheaply than by opening the index and calling
<function>amcanreturn</function>, which is the core code's default behavior.
The default behavior should be satisfactory for all other standard
properties.
順序付け演算子をサポートするアクセスメソッドは、AMPROP_DISTANCE_ORDERABLE
の属性検査を実装する必要があります。
なぜなら、コアコードはそれをどうすれば良いか知らないため、NULLを返すからです。
コアコードのデフォルトの動作であるインデックスのオープンとamcanreturn
の呼び出しよりも安価にできるのであれば、AMPROP_RETURNABLE
の検査を実装するのは利点となります。
その他のすべての標準属性に対しては、デフォルトの動作が満足できるもののはずです。
char * ambuildphasename (int64 phasenum);
Return the textual name of the given build phase number.
The phase numbers are those reported during an index build via the
<function>pgstat_progress_update_param</function> interface.
The phase names are then exposed in the
<structname>pg_stat_progress_create_index</structname> view.
指定されたビルドフェーズ番号のテキスト名を返します。
フェーズ番号は、pgstat_progress_update_param
インタフェースを介してインデックス構築中に報告されたものです。
それから、フェーズ名はpg_stat_progress_create_index
ビューで公開されます。
bool amvalidate (Oid opclassoid);
Validate the catalog entries for the specified operator class, so far as
the access method can reasonably do that. For example, this might include
testing that all required support functions are provided.
The <function>amvalidate</function> function must return false if the opclass is
invalid. Problems should be reported with <function>ereport</function>
messages, typically at <literal>INFO</literal> level.
指定の演算子クラスについて、アクセスメソッドが合理的に可能な範囲でカタログエントリを検証します。
例えば、これには必要なすべてのサポート関数が提供されていることのテストが含まれるかもしれません。
amvalidate
関数は演算子クラスが無効なときは偽を返さなければなりません。
問題があれば典型的にはINFO
レベルでereport
メッセージにより報告されます。
void amadjustmembers (Oid opfamilyoid, Oid opclassoid, List *operators, List *functions);
Validate proposed new operator and function members of an operator family,
so far as the access method can reasonably do that, and set their
dependency types if the default is not satisfactory. This is called
during <command>CREATE OPERATOR CLASS</command> and during
<command>ALTER OPERATOR FAMILY ADD</command>; in the latter
case <parameter>opclassoid</parameter> is <literal>InvalidOid</literal>.
The <type>List</type> arguments are lists
of <structname>OpFamilyMember</structname> structs, as defined
in <filename>amapi.h</filename>.
Tests done by this function will typically be a subset of those
performed by <function>amvalidate</function>,
since <function>amadjustmembers</function> cannot assume that it is
seeing a complete set of members. For example, it would be reasonable
to check the signature of a support function, but not to check whether
all required support functions are provided. Any problems can be
reported by throwing an error.
The dependency-related fields of
the <structname>OpFamilyMember</structname> structs are initialized by
the core code to create hard dependencies on the opclass if this
is <command>CREATE OPERATOR CLASS</command>, or soft dependencies on the
opfamily if this is <command>ALTER OPERATOR FAMILY ADD</command>.
<function>amadjustmembers</function> can adjust these fields if some other
behavior is more appropriate. For example, GIN, GiST, and SP-GiST
always set operator members to have soft dependencies on the opfamily,
since the connection between an operator and an opclass is relatively
weak in these index types; so it is reasonable to allow operator members
to be added and removed freely. Optional support functions are typically
also given soft dependencies, so that they can be removed if necessary.
アクセスメソッドが合理的に可能な範囲で提案された新しい演算子族の演算子と関数メンバを検証し、デフォルトが不十分なら依存型を設定します。
これはCREATE OPERATOR CLASS
とALTER OPERATOR FAMILY ADD
の実行中に呼び出されます。
後者の場合、opclassoid
はInvalidOid
です。
List
引数はamapi.h
で定義されているOpFamilyMember
構造体のリストです。
この関数で実施されるテストは典型的にはamvalidate
が行うテストのサブセットです。
なぜなら、amadjustmembers
はメンバの集合のすべてを観察しているとは仮定することができないからです。
たとえば、サポート関数の呼び出し形式を検証することは妥当ですが、必要なすべてのサポート関数が提供されていることを検証するのは妥当ではないからです。
問題が発生すればどの場合でもエラーが生じます。
OpFamilyMember
構造体の依存性に関するフィールドに、CREATE OPERATOR CLASS
の場合にはopclassにコアコードがハード依存性で初期化します。ALTER OPERATOR FAMILY ADD
ならばopfamilyをソフト依存性で初期化します。
それ以外の振る舞いがより適正ならば、amadjustmembers
でこれらのフィールドを調整することができます。
たとえば、GIN、GiST、SP-GiSTのようなインデックス形式では演算子とopclassの関連性が相対的低く、演算子メンバの追加削除を自由に行うことが合理的であるため、これらの演算子メンバにおいてはopfamilyに常にソフト依存性が設定されます。
また、必要ならば削除可能にするために、追加のサポート関数にソフト依存性を設定するのが一般的です。
The purpose of an index, of course, is to support scans for tuples matching
an indexable <literal>WHERE</literal> condition, often called a
<firstterm>qualifier</firstterm> or <firstterm>scan key</firstterm>. The semantics of
index scanning are described more fully in <xref linkend="index-scanning"/>,
below. An index access method can support <quote>plain</quote> index scans,
<quote>bitmap</quote> index scans, or both. The scan-related functions that an
index access method must or may provide are:
当然ながらインデックスの目的は、よく修飾子やスキャンキーと呼ばれる、インデックス可能なWHERE
条件を満たすタプルのスキャンをサポートすることです。
インデックススキャンのセマンティクスは後の62.3でより詳しく説明します。
インデックスアクセスメソッドは「単純」インデックススキャン、「ビットマップ」インデックススキャン、またはこれら双方を提供します。
インデックスアクセスメソッドが提供しなければならない、もしくは提供する可能性のあるスキャン関連の関数を以下に示します。
IndexScanDesc ambeginscan (Relation indexRelation, int nkeys, int norderbys);
Prepare for an index scan. The <literal>nkeys</literal> and <literal>norderbys</literal>
parameters indicate the number of quals and ordering operators that will be
used in the scan; these may be useful for space allocation purposes.
Note that the actual values of the scan keys aren't provided yet.
The result must be a palloc'd struct.
For implementation reasons the index access method
<emphasis>must</emphasis> create this struct by calling
<function>RelationGetIndexScan()</function>. In most cases
<function>ambeginscan</function> does little beyond making that call and perhaps
acquiring locks;
the interesting parts of index-scan startup are in <function>amrescan</function>.
インデックススキャンを準備します。
nkeys
およびnorderbys
パラメータは、スキャンで使用される等価性演算子と順序付け演算子の個数を表します。
これらは領域を割り当てる目的で便利かもしれません。
スキャンキーの実値がまだ提供されていないことに注意してください。
結果はpallocした構造体でなければなりません。
実装上の理由により、インデックスアクセスメソッドはRelationGetIndexScan()
呼び出しによってこの構造体を作成しなければなりません。
ほとんどの場合、ambeginscan
はこの呼び出しとおそらくロックの獲得の他にはほとんど何も行いません。
インデックススキャンを始める際の興味深い部分は、amrescan
にあります。
void amrescan (IndexScanDesc scan, ScanKey keys, int nkeys, ScanKey orderbys, int norderbys);
Start or restart an index scan, possibly with new scan keys. (To restart
using previously-passed keys, NULL is passed for <literal>keys</literal> and/or
<literal>orderbys</literal>.) Note that it is not allowed for
the number of keys or order-by operators to be larger than
what was passed to <function>ambeginscan</function>. In practice the restart
feature is used when a new outer tuple is selected by a nested-loop join
and so a new key comparison value is needed, but the scan key structure
remains the same.
インデックススキャンを起動または再起動します。
スキャンキーを新しくすることもできます。
(過去に渡されたキーを使用して再起動するには、key
、orderbys
、またはその両方にNULLを渡します。)
ambeginscan
に渡したキー演算子、順序付け演算子の個数より多くを使用することはできないことに注意してください。
実際には、ネステッドループ結合によって新しい外部タプルが選択され、同じスキャンキー構造体で新しいキー比較値が必要とされた場合に、この再起動機能は使用されます。
bool amgettuple (IndexScanDesc scan, ScanDirection direction);
Fetch the next tuple in the given scan, moving in the given
direction (forward or backward in the index). Returns true if a tuple was
obtained, false if no matching tuples remain. In the true case the tuple
TID is stored into the <literal>scan</literal> structure. Note that
<quote>success</quote> means only that the index contains an entry that matches
the scan keys, not that the tuple necessarily still exists in the heap or
will pass the caller's snapshot test. On success, <function>amgettuple</function>
must also set <literal>scan->xs_recheck</literal> to true or false.
False means it is certain that the index entry matches the scan keys.
True means this is not certain, and the conditions represented by the
scan keys must be rechecked against the heap tuple after fetching it.
This provision supports <quote>lossy</quote> index operators.
Note that rechecking will extend only to the scan conditions; a partial
index predicate (if any) is never rechecked by <function>amgettuple</function>
callers.
指定されたスキャン内から指定された方向(インデックス内の前方または後方)で次のタプルを取り出します。
タプルを取り出した場合は真を返します。
一致するタプルが残っていない場合は偽を返します。
真の場合、そのタプルのTIDがscan
に格納されます。
「成功」とは、単にインデックスにスキャンキーに一致する項目があったことを意味しているだけです。
タプルが必ずヒープ内に存在することや、呼び出し元のスナップショットの試験を通過したことを意味してはいません。
成功の暁には、amgettuple
はscan->xs_recheck
を真か偽かに設定しなければなりません。
偽の意味は、インデックス項目が確実にスキャンキーに一致することです。
真の意味は、これが確かなことではなく、スキャンキーで表示された条件がヒープタプルを取り出された後で再検査されなければならないことです。
この対策は「非可逆」インデックス演算子をサポートします。
再検査はスキャン条件のみに拡大適用されることに注意してください。
部分インデックス述語(もしあれば)はamgettuple
呼び出し元で決して再検査されません。
If the index supports <link linkend="indexes-index-only-scans">index-only
scans</link> (i.e., <function>amcanreturn</function> returns true for any
of its columns),
then on success the AM must also check <literal>scan->xs_want_itup</literal>,
and if that is true it must return the originally indexed data for the
index entry. Columns for which <function>amcanreturn</function> returns
false can be returned as nulls.
The data can be returned in the form of an
<structname>IndexTuple</structname> pointer stored at <literal>scan->xs_itup</literal>,
with tuple descriptor <literal>scan->xs_itupdesc</literal>; or in the form of
a <structname>HeapTuple</structname> pointer stored at <literal>scan->xs_hitup</literal>,
with tuple descriptor <literal>scan->xs_hitupdesc</literal>. (The latter
format should be used when reconstructing data that might possibly not fit
into an <structname>IndexTuple</structname>.) In either case,
management of the data referenced by the pointer is the access method's
responsibility. The data must remain good at least until the next
<function>amgettuple</function>, <function>amrescan</function>, or <function>amendscan</function>
call for the scan.
そのインデックスがインデックスオンリースキャンをサポートしている場合(つまりamcanreturn
がすべての列に対して真を返す場合)、そのアクセスメソッドはスキャンが成功したならばscan->xs_want_itup
も確認し、それが真の場合、そのインデックスエントリに対応する元のインデックスされたデータを返さなければなりません。
amcanreturn
が列に対して偽を返す場合、その列はNULLとして返されます。
返却されるデータは、scan->xs_itupdesc
タプルディスクリプタとともにscan->xs_itup
に格納されたIndexTuple
ポインタの形式か、あるいは、scan->xs_hitupdesc
タプルディスクリプタとともにscan->xs_hitup
に格納されたHeapTuple
ポインタの形式です。
(後者の形式は、再構成されたデータがIndexTuple
に収まらない場合に使用するべきです。)
どちらの場合でも、そのポインタが参照するデータの管理はアクセスメソッドの責任です。
データは少なくともamgettuple
、amrescan
またはamendscan
によってスキャンされるまでよい状態を保たなくてはなりません。
The <function>amgettuple</function> function need only be provided if the access
method supports <quote>plain</quote> index scans. If it doesn't, the
<structfield>amgettuple</structfield> field in its <structname>IndexAmRoutine</structname>
struct must be set to NULL.
amgettuple
関数は、アクセスメソッドが「単純」インデックススキャンをサポートするときのみ提供される必要があります。
そうでなければ、IndexAmRoutine
構造体のamgettuple
フィールドはNULLに設定されなければなりません。
int64 amgetbitmap (IndexScanDesc scan, TIDBitmap *tbm);
Fetch all tuples in the given scan and add them to the caller-supplied
<type>TIDBitmap</type> (that is, OR the set of tuple IDs into whatever set is already
in the bitmap). The number of tuples fetched is returned (this might be
just an approximate count, for instance some AMs do not detect duplicates).
While inserting tuple IDs into the bitmap, <function>amgetbitmap</function> can
indicate that rechecking of the scan conditions is required for specific
tuple IDs. This is analogous to the <literal>xs_recheck</literal> output parameter
of <function>amgettuple</function>. Note: in the current implementation, support
for this feature is conflated with support for lossy storage of the bitmap
itself, and therefore callers recheck both the scan conditions and the
partial index predicate (if any) for recheckable tuples. That might not
always be true, however.
<function>amgetbitmap</function> and
<function>amgettuple</function> cannot be used in the same index scan; there
are other restrictions too when using <function>amgetbitmap</function>, as explained
in <xref linkend="index-scanning"/>.
指定されたスキャンから全てのタプルを取り出し、呼び出し側が提供するTIDBitmap
にそれらを付加します
(つまり、既にビットマップ内にある集合とタプルIDの集合とのORを取ります)。
取り出されたタプル数が返されます(例えばいくつかのAMは重複を検出しませんので、これは単なる概算です)。
タプルIDをビットマップに挿入する間、amgetbitmap
は特定のタプルIDに必要なスキャン条件の再検査を示すことが可能です。
これはamgettuple
のxs_recheck
出力パラメータに類似しています。
注意:現在の実装においてこの機能の提供はビットマップそのものの非可逆格納を提供するのに結びついていて、したがって呼び出し側はスキャン条件と部分インデックスの述部(存在すれば)を再検査可能なタプルに対して再検査します。
とは言っても常に正しいとは限りません。
amgetbitmap
およびamgettuple
を同じインデックススキャン内で使用することはできません。
62.3で説明した通り、amgetbitmap
を使用する場合には他にも制限があります。
The <function>amgetbitmap</function> function need only be provided if the access
method supports <quote>bitmap</quote> index scans. If it doesn't, the
<structfield>amgetbitmap</structfield> field in its <structname>IndexAmRoutine</structname>
struct must be set to NULL.
amgetbitmap
関数はアクセスメソッドが「ビットマップ」インデックススキャンをサポートしている場合のみ必要です。
そうでなければ、IndexAmRoutine
構造体の中のamgetbitmap
フィールドはNULLに設定されなければなりません。
void amendscan (IndexScanDesc scan);
End a scan and release resources. The <literal>scan</literal> struct itself
should not be freed, but any locks or pins taken internally by the
access method must be released, as well as any other memory allocated
by <function>ambeginscan</function> and other scan-related functions.
スキャンを停止し、リソースを解放します。
scan
構造体自体は解放すべきではありません。
アクセスメソッドで内部的に取られたロックやピンは、ambeginscan
や他のスキャン関連の関数により確保されたメモリと同様に解放しなければなりません。
void ammarkpos (IndexScanDesc scan);
Mark current scan position. The access method need only support one remembered scan position per scan. 現在のスキャン位置を記録します。 アクセスメソッドは1スキャン当たり1つの記録済みスキャンのみをサポートしなければなりません。
The <function>ammarkpos</function> function need only be provided if the access
method supports ordered scans. If it doesn't,
the <structfield>ammarkpos</structfield> field in its <structname>IndexAmRoutine</structname>
struct may be set to NULL.
ammarkpos
関数はアクセスメソッドが順序付けされたスキャンをサポートする場合にのみ提供する必要があります。
そうでなければ、そのIndexAmRoutine
構造体のammarkpos
フィールドはNULLに設定しても構いません。
void amrestrpos (IndexScanDesc scan);
Restore the scan to the most recently marked position. もっとも最近に記録された位置にスキャンを戻します。
The <function>amrestrpos</function> function need only be provided if the access
method supports ordered scans. If it doesn't,
the <structfield>amrestrpos</structfield> field in its <structname>IndexAmRoutine</structname>
struct may be set to NULL.
amrestrpos
関数はアクセスメソッドが順序付けされたスキャンをサポートする場合にのみ提供する必要があります。
そうでなければ、そのIndexAmRoutine
構造体のamrestrpos
フィールドはNULLに設定しても構いません。
In addition to supporting ordinary index scans, some types of index may wish to support <firstterm>parallel index scans</firstterm>, which allow multiple backends to cooperate in performing an index scan. The index access method should arrange things so that each cooperating process returns a subset of the tuples that would be performed by an ordinary, non-parallel index scan, but in such a way that the union of those subsets is equal to the set of tuples that would be returned by an ordinary, non-parallel index scan. Furthermore, while there need not be any global ordering of tuples returned by a parallel scan, the ordering of that subset of tuples returned within each cooperating backend must match the requested ordering. The following functions may be implemented to support parallel index scans: 通常のインデックススキャンのサポートに加え、ある種のインデックスは、複数のバックエンドが協調してインデックススキャンを実行するパラレルインデックススキャンをサポートすることができます。 インデックスアクセスメソッドは、協調するプロセスが、通常の非パラレルインデックススキャンが実行対象とする行のサブセットを返しつつ、しかもそれらのサブセットの合計が、通常の非パラレルインデックススキャンが返すタプルの集合と同じになるように調整しなければなりません。 それだけでなく、パラレルスキャンが返すタプル全体の順序付けが想定されていない場合でも、協調するバックエンドが返すサブセットのタプルの順序付けは、要求された順序付けと一致しなければなりません。 パラレルインデックススキャンをサポートするために、以下の関数を実装することができます。
Size amestimateparallelscan (int nkeys, int norderbys);
Estimate and return the number of bytes of dynamic shared memory which
the access method will be needed to perform a parallel scan. (This number
is in addition to, not in lieu of, the amount of space needed for
AM-independent data in <structname>ParallelIndexScanDescData</structname>.)
パラレルスキャンを実行するために、アクセスメソッドによって必要とされる動的共有メモリのバイト数を推測し、返します。
(この数値は、ParallelIndexScanDescData
のAM独立データに必要となる量に追加するための値であり、それを置き換えるものではありません。)
The <literal>nkeys</literal> and <literal>norderbys</literal>
parameters indicate the number of quals and ordering operators that will be
used in the scan; the same values will be passed to <function>amrescan</function>.
Note that the actual values of the scan keys aren't provided yet.
《機械翻訳》nkeys
およびnorderbys
パラメータは、スキャンで使用される等価性演算子と順序付け演算子の個数を表します。
これらの値はamrescan
にも渡されます。
スキャンキーの実際の値はまだ提供されていません。
It is not necessary to implement this function for access methods which do not support parallel scans or for which the number of additional bytes of storage required is zero. パラレルスキャンをサポートしない、あるいはメモリ領域への追加のバイト数が0のアクセスメソッドでは、この関数を実装する必要はありません。
void aminitparallelscan (void *target);
This function will be called to initialize dynamic shared memory at the
beginning of a parallel scan. <parameter>target</parameter> will point to at least
the number of bytes previously returned by
<function>amestimateparallelscan</function>, and this function may use that
amount of space to store whatever data it wishes.
この関数は、パラレルスキャンの最初に動的共有メモリを初期化するために呼ばれます。
target
は、前もってamestimateparallelscan
が返したバイト数を少なくとも持つ領域を指し、この関数はその分だけのスペースを使って必要なデータを保管することができます。
It is not necessary to implement this function for access methods which do not support parallel scans or in cases where the shared memory space required needs no initialization. パラレルスキャンをサポートしない、あるいは共有メモリスペースの初期化が必要ないアクセスメソッドでは、この関数を実装する必要はありません。
void amparallelrescan (IndexScanDesc scan);
This function, if implemented, will be called when a parallel index scan
must be restarted. It should reset any shared state set up by
<function>aminitparallelscan</function> such that the scan will be restarted from
the beginning.
実装された場合、この関数はパラレルインデックススキャンを再起動しなければならない時に呼ばれます。
この関数は、aminitparallelscan
が設定した共有状態を初期化し、スキャンが最初から再開できるようにします。