begriffs open source - ai-pg/blob - full-docs/src/sgml/html/index-functions.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>63.2. Index Access Method Functions</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="index-api.html" title="63.1. Basic API Structure for Indexes" /><link rel="next" href="index-scanning.html" title="63.3. Index Scanning" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">63.2. Index Access Method Functions</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="index-api.html" title="63.1. Basic API Structure for Indexes">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="indexam.html" title="Chapter 63. Index Access Method Interface Definition">Up</a></td><th width="60%" align="center">Chapter 63. Index Access Method Interface Definition</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="index-scanning.html" title="63.3. Index Scanning">Next</a></td></tr></table><hr /></div><div class="sect1" id="INDEX-FUNCTIONS"><div class="titlepage"><div><div><h2 class="title" style="clear: both">63.2. Index Access Method Functions <a href="#INDEX-FUNCTIONS" class="id_link">#</a></h2></div></div></div><p>
   3    The index construction and maintenance functions that an index access
   4    method must provide in <code class="structname">IndexAmRoutine</code> are:
   5   </p><p>
   6 </p><pre class="programlisting">
   7 IndexBuildResult *
   8 ambuild (Relation heapRelation,
   9          Relation indexRelation,
  10          IndexInfo *indexInfo);
  11 </pre><p>
  12    Build a new index.  The index relation has been physically created,
  13    but is empty.  It must be filled in with whatever fixed data the
  14    access method requires, plus entries for all tuples already existing
  15    in the table.  Ordinarily the <code class="function">ambuild</code> function will call
  16    <code class="function">table_index_build_scan()</code> to scan the table for existing tuples
  17    and compute the keys that need to be inserted into the index.
  18    The function must return a palloc'd struct containing statistics about
  19    the new index.
  20    The <code class="structfield">amcanbuildparallel</code> flag indicates whether
  21    the access method supports parallel index builds. When set to <code class="literal">true</code>,
  22    the system will attempt to allocate parallel workers for the build.
  23    Access methods supporting only non-parallel index builds should leave
  24    this flag set to <code class="literal">false</code>.
  25   </p><p>
  26 </p><pre class="programlisting">
  27 void
  28 ambuildempty (Relation indexRelation);
  29 </pre><p>
  30    Build an empty index, and write it to the initialization fork (<code class="symbol">INIT_FORKNUM</code>)
  31    of the given relation.  This method is called only for unlogged indexes; the
  32    empty index written to the initialization fork will be copied over the main
  33    relation fork on each server restart.
  34   </p><p>
  35 </p><pre class="programlisting">
  36 bool
  37 aminsert (Relation indexRelation,
  38           Datum *values,
  39           bool *isnull,
  40           ItemPointer heap_tid,
  41           Relation heapRelation,
  42           IndexUniqueCheck checkUnique,
  43           bool indexUnchanged,
  44           IndexInfo *indexInfo);
  45 </pre><p>
  46    Insert a new tuple into an existing index.  The <code class="literal">values</code> and
  47    <code class="literal">isnull</code> arrays give the key values to be indexed, and
  48    <code class="literal">heap_tid</code> is the TID to be indexed.
  49    If the access method supports unique indexes (its
  50    <code class="structfield">amcanunique</code> flag is true) then
  51    <code class="literal">checkUnique</code> indicates the type of uniqueness check to
  52    perform.  This varies depending on whether the unique constraint is
  53    deferrable; see <a class="xref" href="index-unique-checks.html" title="63.5. Index Uniqueness Checks">Section 63.5</a> for details.
  54    Normally the access method only needs the <code class="literal">heapRelation</code>
  55    parameter when performing uniqueness checking (since then it will have to
  56    look into the heap to verify tuple liveness).
  57   </p><p>
  58    The <code class="literal">indexUnchanged</code> Boolean value gives a hint
  59    about the nature of the tuple to be indexed.  When it is true,
  60    the tuple is a duplicate of some existing tuple in the index.  The
  61    new tuple is a logically unchanged successor MVCC tuple version.  This
  62    happens when an <code class="command">UPDATE</code> takes place that does not
  63    modify any columns covered by the index, but nevertheless requires a
  64    new version in the index.  The index AM may use this hint to decide
  65    to apply bottom-up index deletion in parts of the index where many
  66    versions of the same logical row accumulate.  Note that updating a non-key
  67    column or a column that only appears in a partial index predicate does not
  68    affect the value of <code class="literal">indexUnchanged</code>.  The core code
  69    determines each tuple's <code class="literal">indexUnchanged</code> value using a low
  70    overhead approach that allows both false positives and false negatives.
  71    Index AMs must not treat <code class="literal">indexUnchanged</code> as an
  72    authoritative source of information about tuple visibility or versioning.
  73   </p><p>
  74    The function's Boolean result value is significant only when
  75    <code class="literal">checkUnique</code> is <code class="literal">UNIQUE_CHECK_PARTIAL</code>.
  76    In this case a true result means the new entry is known unique, whereas
  77    false means it might be non-unique (and a deferred uniqueness check must
  78    be scheduled).  For other cases a constant false result is recommended.
  79   </p><p>
  80    Some indexes might not index all tuples.  If the tuple is not to be
  81    indexed, <code class="function">aminsert</code> should just return without doing anything.
  82   </p><p>
  83    If the index AM wishes to cache data across successive index insertions
  84    within an SQL statement, it can allocate space
  85    in <code class="literal">indexInfo-&gt;ii_Context</code> and store a pointer to the
  86    data in <code class="literal">indexInfo-&gt;ii_AmCache</code> (which will be NULL
  87    initially).  If resources other than memory have to be released after
  88    index insertions, <code class="function">aminsertcleanup</code> may be provided,
  89    which will be called before the memory is released.
  90   </p><p>
  91 </p><pre class="programlisting">
  92 void
  93 aminsertcleanup (Relation indexRelation,
  94                  IndexInfo *indexInfo);
  95 </pre><p>
  96    Clean up state that was maintained across successive inserts in
  97    <code class="literal">indexInfo-&gt;ii_AmCache</code>. This is useful if the data
  98    requires additional cleanup steps (e.g., releasing pinned buffers), and
  99    simply releasing the memory is not sufficient.
 100   </p><p>
 101 </p><pre class="programlisting">
 102 IndexBulkDeleteResult *
 103 ambulkdelete (IndexVacuumInfo *info,
 104               IndexBulkDeleteResult *stats,
 105               IndexBulkDeleteCallback callback,
 106               void *callback_state);
 107 </pre><p>
 108    Delete tuple(s) from the index.  This is a <span class="quote">“<span class="quote">bulk delete</span>”</span> operation
 109    that is intended to be implemented by scanning the whole index and checking
 110    each entry to see if it should be deleted.
 111    The passed-in <code class="literal">callback</code> function must be called, in the style
 112    <code class="literal">callback(<em class="replaceable"><code>TID</code></em>, callback_state) returns bool</code>,
 113    to determine whether any particular index entry, as identified by its
 114    referenced TID, is to be deleted.  Must return either NULL or a palloc'd
 115    struct containing statistics about the effects of the deletion operation.
 116    It is OK to return NULL if no information needs to be passed on to
 117    <code class="function">amvacuumcleanup</code>.
 118   </p><p>
 119    Because of limited <code class="varname">maintenance_work_mem</code>,
 120    <code class="function">ambulkdelete</code> might need to be called more than once when many
 121    tuples are to be deleted.  The <code class="literal">stats</code> argument is the result
 122    of the previous call for this index (it is NULL for the first call within a
 123    <code class="command">VACUUM</code> operation).  This allows the AM to accumulate statistics
 124    across the whole operation.  Typically, <code class="function">ambulkdelete</code> will
 125    modify and return the same struct if the passed <code class="literal">stats</code> is not
 126    null.
 127   </p><p>
 128 </p><pre class="programlisting">
 129 IndexBulkDeleteResult *
 130 amvacuumcleanup (IndexVacuumInfo *info,
 131                  IndexBulkDeleteResult *stats);
 132 </pre><p>
 133    Clean up after a <code class="command">VACUUM</code> operation (zero or more
 134    <code class="function">ambulkdelete</code> calls).  This does not have to do anything
 135    beyond returning index statistics, but it might perform bulk cleanup
 136    such as reclaiming empty index pages.  <code class="literal">stats</code> is whatever the
 137    last <code class="function">ambulkdelete</code> call returned, or NULL if
 138    <code class="function">ambulkdelete</code> was not called because no tuples needed to be
 139    deleted.  If the result is not NULL it must be a palloc'd struct.
 140    The statistics it contains will be used to update <code class="structname">pg_class</code>,
 141    and will be reported by <code class="command">VACUUM</code> if <code class="literal">VERBOSE</code> is given.
 142    It is OK to return NULL if the index was not changed at all during the
 143    <code class="command">VACUUM</code> operation, but otherwise correct stats should
 144    be returned.
 145   </p><p>
 146    <code class="function">amvacuumcleanup</code> will also be called at completion of an
 147    <code class="command">ANALYZE</code> operation.  In this case <code class="literal">stats</code> is always
 148    NULL and any return value will be ignored.  This case can be distinguished
 149    by checking <code class="literal">info-&gt;analyze_only</code>.  It is recommended
 150    that the access method do nothing except post-insert cleanup in such a
 151    call, and that only in an autovacuum worker process.
 152   </p><p>
 153 </p><pre class="programlisting">
 154 bool
 155 amcanreturn (Relation indexRelation, int attno);
 156 </pre><p>
 157    Check whether the index can support <a class="link" href="indexes-index-only-scans.html" title="11.9. Index-Only Scans and Covering Indexes"><em class="firstterm">index-only scans</em></a> on
 158    the given column, by returning the column's original indexed value.
 159    The attribute number is 1-based, i.e., the first column's attno is 1.
 160    Returns true if supported, else false.
 161    This function should always return true for included columns
 162    (if those are supported), since there's little point in an included
 163    column that can't be retrieved.
 164    If the access method does not support index-only scans at all,
 165    the <code class="structfield">amcanreturn</code> field in its <code class="structname">IndexAmRoutine</code>
 166    struct can be set to NULL.
 167   </p><p>
 168 </p><pre class="programlisting">
 169 void
 170 amcostestimate (PlannerInfo *root,
 171                 IndexPath *path,
 172                 double loop_count,
 173                 Cost *indexStartupCost,
 174                 Cost *indexTotalCost,
 175                 Selectivity *indexSelectivity,
 176                 double *indexCorrelation,
 177                 double *indexPages);
 178 </pre><p>
 179    Estimate the costs of an index scan.  This function is described fully
 180    in <a class="xref" href="index-cost-estimation.html" title="63.6. Index Cost Estimation Functions">Section 63.6</a>, below.
 181   </p><p>
 182 </p><pre class="programlisting">
 183 int
 184 amgettreeheight (Relation rel);
 185 </pre><p>
 186    Compute the height of a tree-shaped index.  This information is supplied to
 187    the <code class="function">amcostestimate</code> function in
 188    <code class="literal">path-&gt;indexinfo-&gt;tree_height</code> and can be used to support
 189    the cost estimation.  The result is not used anywhere else, so this
 190    function can actually be used to compute any kind of data (that fits into
 191    an integer) about the index that the cost estimation function might want to
 192    know.  If the computation is expensive, it could be useful to cache the
 193    result as part of <code class="literal">RelationData.rd_amcache</code>.
 194   </p><p>
 195 </p><pre class="programlisting">
 196 bytea *
 197 amoptions (ArrayType *reloptions,
 198            bool validate);
 199 </pre><p>
 200    Parse and validate the reloptions array for an index.  This is called only
 201    when a non-null reloptions array exists for the index.
 202    <em class="parameter"><code>reloptions</code></em> is a <code class="type">text</code> array containing entries of the
 203    form <em class="replaceable"><code>name</code></em><code class="literal">=</code><em class="replaceable"><code>value</code></em>.
 204    The function should construct a <code class="type">bytea</code> value, which will be copied
 205    into the <code class="structfield">rd_options</code> field of the index's relcache entry.
 206    The data contents of the <code class="type">bytea</code> value are open for the access
 207    method to define; most of the standard access methods use struct
 208    <code class="structname">StdRdOptions</code>.
 209    When <em class="parameter"><code>validate</code></em> is true, the function should report a suitable
 210    error message if any of the options are unrecognized or have invalid
 211    values; when <em class="parameter"><code>validate</code></em> is false, invalid entries should be
 212    silently ignored.  (<em class="parameter"><code>validate</code></em> is false when loading options
 213    already stored in <code class="structname">pg_catalog</code>; an invalid entry could only
 214    be found if the access method has changed its rules for options, and in
 215    that case ignoring obsolete entries is appropriate.)
 216    It is OK to return NULL if default behavior is wanted.
 217   </p><p>
 218 </p><pre class="programlisting">
 219 bool
 220 amproperty (Oid index_oid, int attno,
 221             IndexAMProperty prop, const char *propname,
 222             bool *res, bool *isnull);
 223 </pre><p>
 224    The <code class="function">amproperty</code> method allows index access methods to override
 225    the default behavior of <code class="function">pg_index_column_has_property</code>
 226    and related functions.
 227    If the access method does not have any special behavior for index property
 228    inquiries, the <code class="structfield">amproperty</code> field in
 229    its <code class="structname">IndexAmRoutine</code> struct can be set to NULL.
 230    Otherwise, the <code class="function">amproperty</code> method will be called with
 231    <em class="parameter"><code>index_oid</code></em> and <em class="parameter"><code>attno</code></em> both zero for
 232    <code class="function">pg_indexam_has_property</code> calls,
 233    or with <em class="parameter"><code>index_oid</code></em> valid and <em class="parameter"><code>attno</code></em> zero for
 234    <code class="function">pg_index_has_property</code> calls,
 235    or with <em class="parameter"><code>index_oid</code></em> valid and <em class="parameter"><code>attno</code></em> greater than
 236    zero for <code class="function">pg_index_column_has_property</code> calls.
 237    <em class="parameter"><code>prop</code></em> is an enum value identifying the property being tested,
 238    while <em class="parameter"><code>propname</code></em> is the original property name string.
 239    If the core code does not recognize the property name
 240    then <em class="parameter"><code>prop</code></em> is <code class="literal">AMPROP_UNKNOWN</code>.
 241    Access methods can define custom property names by
 242    checking <em class="parameter"><code>propname</code></em> for a match (use <code class="function">pg_strcasecmp</code>
 243    to match, for consistency with the core code); for names known to the core
 244    code, it's better to inspect <em class="parameter"><code>prop</code></em>.
 245    If the <code class="structfield">amproperty</code> method returns <code class="literal">true</code> then
 246    it has determined the property test result: it must set <code class="literal">*res</code>
 247    to the Boolean value to return, or set <code class="literal">*isnull</code>
 248    to <code class="literal">true</code> to return a NULL.  (Both of the referenced variables
 249    are initialized to <code class="literal">false</code> before the call.)
 250    If the <code class="structfield">amproperty</code> method returns <code class="literal">false</code> then
 251    the core code will proceed with its normal logic for determining the
 252    property test result.
 253   </p><p>
 254    Access methods that support ordering operators should
 255    implement <code class="literal">AMPROP_DISTANCE_ORDERABLE</code> property testing, as the
 256    core code does not know how to do that and will return NULL.  It may
 257    also be advantageous to implement <code class="literal">AMPROP_RETURNABLE</code> testing,
 258    if that can be done more cheaply than by opening the index and calling
 259    <code class="function">amcanreturn</code>, which is the core code's default behavior.
 260    The default behavior should be satisfactory for all other standard
 261    properties.
 262   </p><p>
 263 </p><pre class="programlisting">
 264 char *
 265 ambuildphasename (int64 phasenum);
 266 </pre><p>
 267    Return the textual name of the given build phase number.
 268    The phase numbers are those reported during an index build via the
 269    <code class="function">pgstat_progress_update_param</code> interface.
 270    The phase names are then exposed in the
 271    <code class="structname">pg_stat_progress_create_index</code> view.
 272   </p><p>
 273 </p><pre class="programlisting">
 274 bool
 275 amvalidate (Oid opclassoid);
 276 </pre><p>
 277    Validate the catalog entries for the specified operator class, so far as
 278    the access method can reasonably do that.  For example, this might include
 279    testing that all required support functions are provided.
 280    The <code class="function">amvalidate</code> function must return false if the opclass is
 281    invalid.  Problems should be reported with <code class="function">ereport</code>
 282    messages, typically at <code class="literal">INFO</code> level.
 283   </p><p>
 284 </p><pre class="programlisting">
 285 void
 286 amadjustmembers (Oid opfamilyoid,
 287                  Oid opclassoid,
 288                  List *operators,
 289                  List *functions);
 290 </pre><p>
 291    Validate proposed new operator and function members of an operator family,
 292    so far as the access method can reasonably do that, and set their
 293    dependency types if the default is not satisfactory.  This is called
 294    during <code class="command">CREATE OPERATOR CLASS</code> and during
 295    <code class="command">ALTER OPERATOR FAMILY ADD</code>; in the latter
 296    case <em class="parameter"><code>opclassoid</code></em> is <code class="literal">InvalidOid</code>.
 297    The <code class="type">List</code> arguments are lists
 298    of <code class="structname">OpFamilyMember</code> structs, as defined
 299    in <code class="filename">amapi.h</code>.
 300
 301    Tests done by this function will typically be a subset of those
 302    performed by <code class="function">amvalidate</code>,
 303    since <code class="function">amadjustmembers</code> cannot assume that it is
 304    seeing a complete set of members.  For example, it would be reasonable
 305    to check the signature of a support function, but not to check whether
 306    all required support functions are provided.  Any problems can be
 307    reported by throwing an error.
 308
 309    The dependency-related fields of
 310    the <code class="structname">OpFamilyMember</code> structs are initialized by
 311    the core code to create hard dependencies on the opclass if this
 312    is <code class="command">CREATE OPERATOR CLASS</code>, or soft dependencies on the
 313    opfamily if this is <code class="command">ALTER OPERATOR FAMILY ADD</code>.
 314    <code class="function">amadjustmembers</code> can adjust these fields if some other
 315    behavior is more appropriate.  For example, GIN, GiST, and SP-GiST
 316    always set operator members to have soft dependencies on the opfamily,
 317    since the connection between an operator and an opclass is relatively
 318    weak in these index types; so it is reasonable to allow operator members
 319    to be added and removed freely.  Optional support functions are typically
 320    also given soft dependencies, so that they can be removed if necessary.
 321   </p><p>
 322    The purpose of an index, of course, is to support scans for tuples matching
 323    an indexable <code class="literal">WHERE</code> condition, often called a
 324    <em class="firstterm">qualifier</em> or <em class="firstterm">scan key</em>.  The semantics of
 325    index scanning are described more fully in <a class="xref" href="index-scanning.html" title="63.3. Index Scanning">Section 63.3</a>,
 326    below.  An index access method can support <span class="quote">“<span class="quote">plain</span>”</span> index scans,
 327    <span class="quote">“<span class="quote">bitmap</span>”</span> index scans, or both.  The scan-related functions that an
 328    index access method must or may provide are:
 329   </p><p>
 330 </p><pre class="programlisting">
 331 IndexScanDesc
 332 ambeginscan (Relation indexRelation,
 333              int nkeys,
 334              int norderbys);
 335 </pre><p>
 336    Prepare for an index scan.  The <code class="literal">nkeys</code> and <code class="literal">norderbys</code>
 337    parameters indicate the number of quals and ordering operators that will be
 338    used in the scan; these may be useful for space allocation purposes.
 339    Note that the actual values of the scan keys aren't provided yet.
 340    The result must be a palloc'd struct.
 341    For implementation reasons the index access method
 342    <span class="emphasis"><em>must</em></span> create this struct by calling
 343    <code class="function">RelationGetIndexScan()</code>.  In most cases
 344    <code class="function">ambeginscan</code> does little beyond making that call and perhaps
 345    acquiring locks;
 346    the interesting parts of index-scan startup are in <code class="function">amrescan</code>.
 347   </p><p>
 348 </p><pre class="programlisting">
 349 void
 350 amrescan (IndexScanDesc scan,
 351           ScanKey keys,
 352           int nkeys,
 353           ScanKey orderbys,
 354           int norderbys);
 355 </pre><p>
 356    Start or restart an index scan, possibly with new scan keys.  (To restart
 357    using previously-passed keys, NULL is passed for <code class="literal">keys</code> and/or
 358    <code class="literal">orderbys</code>.)  Note that it is not allowed for
 359    the number of keys or order-by operators to be larger than
 360    what was passed to <code class="function">ambeginscan</code>.  In practice the restart
 361    feature is used when a new outer tuple is selected by a nested-loop join
 362    and so a new key comparison value is needed, but the scan key structure
 363    remains the same.
 364   </p><p>
 365 </p><pre class="programlisting">
 366 bool
 367 amgettuple (IndexScanDesc scan,
 368             ScanDirection direction);
 369 </pre><p>
 370    Fetch the next tuple in the given scan, moving in the given
 371    direction (forward or backward in the index).  Returns true if a tuple was
 372    obtained, false if no matching tuples remain.  In the true case the tuple
 373    TID is stored into the <code class="literal">scan</code> structure.  Note that
 374    <span class="quote">“<span class="quote">success</span>”</span> means only that the index contains an entry that matches
 375    the scan keys, not that the tuple necessarily still exists in the heap or
 376    will pass the caller's snapshot test.  On success, <code class="function">amgettuple</code>
 377    must also set <code class="literal">scan-&gt;xs_recheck</code> to true or false.
 378    False means it is certain that the index entry matches the scan keys.
 379    True means this is not certain, and the conditions represented by the
 380    scan keys must be rechecked against the heap tuple after fetching it.
 381    This provision supports <span class="quote">“<span class="quote">lossy</span>”</span> index operators.
 382    Note that rechecking will extend only to the scan conditions; a partial
 383    index predicate (if any) is never rechecked by <code class="function">amgettuple</code>
 384    callers.
 385   </p><p>
 386    If the index supports <a class="link" href="indexes-index-only-scans.html" title="11.9. Index-Only Scans and Covering Indexes">index-only
 387    scans</a> (i.e., <code class="function">amcanreturn</code> returns true for any
 388    of its columns),
 389    then on success the AM must also check <code class="literal">scan-&gt;xs_want_itup</code>,
 390    and if that is true it must return the originally indexed data for the
 391    index entry.  Columns for which <code class="function">amcanreturn</code> returns
 392    false can be returned as nulls.
 393    The data can be returned in the form of an
 394    <code class="structname">IndexTuple</code> pointer stored at <code class="literal">scan-&gt;xs_itup</code>,
 395    with tuple descriptor <code class="literal">scan-&gt;xs_itupdesc</code>; or in the form of
 396    a <code class="structname">HeapTuple</code> pointer stored at <code class="literal">scan-&gt;xs_hitup</code>,
 397    with tuple descriptor <code class="literal">scan-&gt;xs_hitupdesc</code>.  (The latter
 398    format should be used when reconstructing data that might possibly not fit
 399    into an <code class="structname">IndexTuple</code>.)  In either case,
 400    management of the data referenced by the pointer is the access method's
 401    responsibility.  The data must remain good at least until the next
 402    <code class="function">amgettuple</code>, <code class="function">amrescan</code>, or <code class="function">amendscan</code>
 403    call for the scan.
 404   </p><p>
 405    The <code class="function">amgettuple</code> function need only be provided if the access
 406    method supports <span class="quote">“<span class="quote">plain</span>”</span> index scans.  If it doesn't, the
 407    <code class="structfield">amgettuple</code> field in its <code class="structname">IndexAmRoutine</code>
 408    struct must be set to NULL.
 409   </p><p>
 410 </p><pre class="programlisting">
 411 int64
 412 amgetbitmap (IndexScanDesc scan,
 413              TIDBitmap *tbm);
 414 </pre><p>
 415    Fetch all tuples in the given scan and add them to the caller-supplied
 416    <code class="type">TIDBitmap</code> (that is, OR the set of tuple IDs into whatever set is already
 417    in the bitmap).  The number of tuples fetched is returned (this might be
 418    just an approximate count, for instance some AMs do not detect duplicates).
 419    While inserting tuple IDs into the bitmap, <code class="function">amgetbitmap</code> can
 420    indicate that rechecking of the scan conditions is required for specific
 421    tuple IDs.  This is analogous to the <code class="literal">xs_recheck</code> output parameter
 422    of <code class="function">amgettuple</code>.  Note: in the current implementation, support
 423    for this feature is conflated with support for lossy storage of the bitmap
 424    itself, and therefore callers recheck both the scan conditions and the
 425    partial index predicate (if any) for recheckable tuples.  That might not
 426    always be true, however.
 427    <code class="function">amgetbitmap</code> and
 428    <code class="function">amgettuple</code> cannot be used in the same index scan; there
 429    are other restrictions too when using <code class="function">amgetbitmap</code>, as explained
 430    in <a class="xref" href="index-scanning.html" title="63.3. Index Scanning">Section 63.3</a>.
 431   </p><p>
 432    The <code class="function">amgetbitmap</code> function need only be provided if the access
 433    method supports <span class="quote">“<span class="quote">bitmap</span>”</span> index scans.  If it doesn't, the
 434    <code class="structfield">amgetbitmap</code> field in its <code class="structname">IndexAmRoutine</code>
 435    struct must be set to NULL.
 436   </p><p>
 437 </p><pre class="programlisting">
 438 void
 439 amendscan (IndexScanDesc scan);
 440 </pre><p>
 441    End a scan and release resources.  The <code class="literal">scan</code> struct itself
 442    should not be freed, but any locks or pins taken internally by the
 443    access method must be released, as well as any other memory allocated
 444    by <code class="function">ambeginscan</code> and other scan-related functions.
 445   </p><p>
 446 </p><pre class="programlisting">
 447 void
 448 ammarkpos (IndexScanDesc scan);
 449 </pre><p>
 450    Mark current scan position.  The access method need only support one
 451    remembered scan position per scan.
 452   </p><p>
 453    The <code class="function">ammarkpos</code> function need only be provided if the access
 454    method supports ordered scans.  If it doesn't,
 455    the <code class="structfield">ammarkpos</code> field in its <code class="structname">IndexAmRoutine</code>
 456    struct may be set to NULL.
 457   </p><p>
 458 </p><pre class="programlisting">
 459 void
 460 amrestrpos (IndexScanDesc scan);
 461 </pre><p>
 462    Restore the scan to the most recently marked position.
 463   </p><p>
 464    The <code class="function">amrestrpos</code> function need only be provided if the access
 465    method supports ordered scans.  If it doesn't,
 466    the <code class="structfield">amrestrpos</code> field in its <code class="structname">IndexAmRoutine</code>
 467    struct may be set to NULL.
 468   </p><p>
 469    In addition to supporting ordinary index scans, some types of index
 470    may wish to support <em class="firstterm">parallel index scans</em>, which allow
 471    multiple backends to cooperate in performing an index scan.  The
 472    index access method should arrange things so that each cooperating
 473    process returns a subset of the tuples that would be performed by
 474    an ordinary, non-parallel index scan, but in such a way that the
 475    union of those subsets is equal to the set of tuples that would be
 476    returned by an ordinary, non-parallel index scan.  Furthermore, while
 477    there need not be any global ordering of tuples returned by a parallel
 478    scan, the ordering of that subset of tuples returned within each
 479    cooperating backend must match the requested ordering.  The following
 480    functions may be implemented to support parallel index scans:
 481   </p><p>
 482 </p><pre class="programlisting">
 483 Size
 484 amestimateparallelscan (Relation indexRelation,
 485                         int nkeys,
 486                         int norderbys);
 487 </pre><p>
 488    Estimate and return the number of bytes of dynamic shared memory which
 489    the access method will be needed to perform a parallel scan.  (This number
 490    is in addition to, not in lieu of, the amount of space needed for
 491    AM-independent data in <code class="structname">ParallelIndexScanDescData</code>.)
 492   </p><p>
 493    The <code class="literal">nkeys</code> and <code class="literal">norderbys</code>
 494    parameters indicate the number of quals and ordering operators that will be
 495    used in the scan; the same values will be passed to <code class="function">amrescan</code>.
 496    Note that the actual values of the scan keys aren't provided yet.
 497   </p><p>
 498    It is not necessary to implement this function for access methods which
 499    do not support parallel scans or for which the number of additional bytes
 500    of storage required is zero.
 501   </p><p>
 502 </p><pre class="programlisting">
 503 void
 504 aminitparallelscan (void *target);
 505 </pre><p>
 506    This function will be called to initialize dynamic shared memory at the
 507    beginning of a parallel scan.  <em class="parameter"><code>target</code></em> will point to at least
 508    the number of bytes previously returned by
 509    <code class="function">amestimateparallelscan</code>, and this function may use that
 510    amount of space to store whatever data it wishes.
 511   </p><p>
 512    It is not necessary to implement this function for access methods which
 513    do not support parallel scans or in cases where the shared memory space
 514    required needs no initialization.
 515   </p><p>
 516 </p><pre class="programlisting">
 517 void
 518 amparallelrescan (IndexScanDesc scan);
 519 </pre><p>
 520    This function, if implemented, will be called when a parallel index scan
 521    must be restarted.  It should reset any shared state set up by
 522    <code class="function">aminitparallelscan</code> such that the scan will be restarted from
 523    the beginning.
 524   </p><p>
 525 </p><pre class="programlisting">
 526 CompareType
 527 amtranslatestrategy (StrategyNumber strategy, Oid opfamily, Oid opcintype);
 528
 529 StrategyNumber
 530 amtranslatecmptype (CompareType cmptype, Oid opfamily, Oid opcintype);
 531 </pre><p>
 532    These functions, if implemented, will be called by the planner and executor
 533    to convert between fixed <code class="type">CompareType</code> values and the specific
 534    strategy numbers used by the access method.  These functions can be
 535    implemented by access methods that implement functionality similar to the
 536    built-in btree or hash access methods, and by implementing these
 537    translations, the system can learn about the semantics of the access
 538    method's operations and can use them in place of btree or hash indexes in
 539    various places.  If the functionality of the access method is not similar
 540    to those built-in access methods, these functions do not need to be
 541    implemented.  If the functions are not implemented, the access method will
 542    be ignored for certain planner and executor decisions, but is otherwise
 543    fully functional.
 544   </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="index-api.html" title="63.1. Basic API Structure for Indexes">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="indexam.html" title="Chapter 63. Index Access Method Interface Definition">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="index-scanning.html" title="63.3. Index Scanning">Next</a></td></tr><tr><td width="40%" align="left" valign="top">63.1. Basic API Structure for Indexes </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 63.3. Index Scanning</td></tr></table></div></body></html>