reset any shared state set up by
   <function>aminitparallelscan</function> such that the scan will be restarted from
   the beginning.
  </para>

  <para>
<programlisting>
CompareType
amtranslatestrategy (StrategyNumber strategy, Oid opfamily, Oid opcintype);

StrategyNumber
amtranslatecmptype (CompareType cmptype, Oid opfamily, Oid opcintype);
</programlisting>
   These functions, if implemented, will be called by the planner and executor
   to convert between fixed <type>CompareType</type> values and the specific
   strategy numbers used by the access method.  These functions can be
   implemented by access methods that implement functionality similar to the
   built-in btree or hash access methods, and by implementing these
   translations, the system can learn about the semantics of the access
   method's operations and can use them in place of btree or hash indexes in
   various places.  If the functionality of the access method is not similar
   to those built-in access methods, these functions do not need to be
   implemented.  If the functions are not implemented, the access method will
   be ignored for certain planner and executor decisions, but is otherwise
   fully functional.
  </para>

 </sect1>

 <sect1 id="index-scanning">
  <title>Index Scanning</title>

  <para>
   In an index scan, the index access method is responsible for regurgitating
   the TIDs of all the tuples it has been told about that match the
   <firstterm>scan keys</firstterm>.  The access method is <emphasis>not</emphasis> involved in
   actually fetching those tuples from the index's parent table, nor in
   determining whether they pass the scan's visibility test or other
   conditions.
  </para>

  <para>
   A scan key is the internal representation of a <literal>WHERE</literal> clause of
   the form <replaceable>index_key</replaceable> <replaceable>operator</replaceable>
   <replaceable>constant</replaceable>, where the index key is one of the columns of the
   index and the operator is one of the members of the operator family
   associated with that index column.  An index scan has zero or more scan
   keys, which are implicitly ANDed &mdash; the returned tuples are expected
   to satisfy all the indicated conditions.
  </para>

  <para>
   The access method can report that the index is <firstterm>lossy</firstterm>, or
   requires rechecks, for a particular query.  This implies that the index
   scan will return all the entries that pass the scan key, plus possibly
   additional entries that do not.  The core system's index-scan machinery
   will then apply the index conditions again to the heap tuple to verify
   whether or not it really should be selected.  If the recheck option is not
   specified, the index scan must return exactly the set of matching entries.
  </para>

  <para>
   Note that it is entirely up to the access method to ensure that it
   correctly finds all and only the entries passing all the given scan keys.
   Also, the core system will simply hand off all the <literal>WHERE</literal>
   clauses that match the index keys and operator families, without any
   semantic analysis to determine whether they are redundant or
   contradictory.  As an example, given
   <literal>WHERE x &gt; 4 AND x &gt; 14</literal> where <literal>x</literal> is a b-tree
   indexed column, it is left to the b-tree <function>amrescan</function> function
   to realize that the first scan key is redundant and can be discarded.
   The extent of preprocessing needed during <function>amrescan</function> will
   depend on the extent to which the index access method needs to reduce
   the scan keys to a <quote>normalized</quote> form.
  </para>

  <para>
   Some access methods return index entries in a well-defined order, others
   do not.  There are actually two different ways that an access method can
   support sorted output:

    <itemizedlist>
     <listitem>
      <para>
       Access methods that always return entries in the natural ordering