ScanKey orderbys,
          int norderbys);
</programlisting>
   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.
  </para>

  <para>
<programlisting>
bool
amgettuple (IndexScanDesc scan,
            ScanDirection direction);
</programlisting>
   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-&gt;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.
  </para>

  <para>
   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-&gt;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-&gt;xs_itup</literal>,
   with tuple descriptor <literal>scan-&gt;xs_itupdesc</literal>; or in the form of
   a <structname>HeapTuple</structname> pointer stored at <literal>scan-&gt;xs_hitup</literal>,
   with tuple descriptor <literal>scan-&gt;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.
  </para>

  <para>
   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.
  </para>

  <para>
<programlisting>
int64
amgetbitmap (IndexScanDesc scan,
             TIDBitmap *tbm);
</programlisting>
   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