Dans un parcours d'index, la méthode d'accès à l'index retourne les TID de toutes les lignes annoncées correspondre aux clés de parcours. La méthode d'accès n'est impliquée ni dans la récupération de ces lignes dans la table parent de l'index, ni dans les tests de qualification temporelle ou autre.

Une clé de parcours est une représentation interne d'une clause WHERE de la forme clé_index opérateur constante, où la clé d'index est une des colonnes de l'index et l'opérateur est un des membres de la famille d'opérateur associée avec cette colonne d'index. Un parcours d'index contient entre aucune et plusieurs clés de parcours qui sont assemblées implicitement avec des AND -- les lignes renvoyées doivent satisfaire toutes les conditions indiquées.

La famille d'opérateur peut indiquer que l'index est à perte pour un opérateur particulier ; ceci implique que le parcours d'index renvoie toutes les entrées qui correspondent à la clé de parcours, avec éventuellement des entrées supplémentaires qui ne correspondent pas. La machinerie du parcours d'index du système principal applique alors cet opérateur au tuple pour vérifier s'il doit bien effectivement être retenu. Pour les opérateurs sans perte, le parcours d'index doit renvoyer exactement l'ensemble d'entrées correspondantes, car il n'y a pas de revérification.

La méthode d'accès doit s'assurer qu'elle trouve correctement toutes les entrées correspondantes aux clés de parcours données, et seulement celles-ci. De plus, le système principal transfert toutes les clauses WHERE qui correspondent aux clés d'index et aux familles d'opérateurs, sans analyse sémantique permettant de déterminer si elles sont redondantes ou contradictoires. Par exemple, étant donné WHERE x > 4 AND x > 14 où x est une colonne indexée B-tree, c'est à la fonction B-tree amrescan de déterminer que la première clé de parcours est redondante et peut être annulée. Le supplément de pré-traitement nécessaire lors de amrescan dépend du niveau de réduction des clés de parcours en une forme « normalisée » nécessaire à la méthode d'accès à l'index.

Certaines méthodes d'accès renvoient des entrées d'index dans un ordre bien défini, d'autres non. Si les entrées sont renvoyées triées, la méthode d'accès doit initialiser pg_am.amcanorder à true pour indiquer qu'elle supporte les parcours triés. Toutes les méthodes d'accès doivent utiliser des numéros de stratégie compatibles btree pour les opérateurs d'égalité et de tri.

La fonction amgettuple dispose d'un argument direction, qui peut être soit ForwardScanDirection (le cas normal) soit BackwardScanDirection. Si le premier appel après amrescan précise BackwardScanDirection, alors l'ensemble des entrées d'index correspondantes est à parcourir de l'arrière vers l'avant plutôt que dans la direction normale (d'avant en arrière). amgettuple doit donc renvoyer la dernière ligne correspondante dans l'index, plutôt que la première, comme cela se fait normalement. (Cela ne survient que pour les méthodes d'accès qui indiquent qu'elles supportent les parcours ordonnés.) Après le premier appel, amgettuple doit être préparé pour continuer le parcours dans la direction adaptée à partir de l'entrée la plus récemment renvoyée.

La méthode d'accès doit supporter le « marquage » d'une position dans un parcours et le renvoi ultérieur à une position marquée. La même position peut être restaurée plusieurs fois. Néanmoins, seule une position doit être mémorisée par parcours ; tout nouvel appel à ammarkpos surcharge la position précédemment marquée.

Les positions du parcours et du marquage doivent être conservées de façon cohérente dans le cas d'insertions et de suppressions concurrentes dans l'index. Il est tout à fait correct qu'une entrée tout juste insérée ne soit pas retournée par un parcours, qui si l'entrée avait existé au démarrage du parcours, aurait été retournée. De même est-il correct qu'un parcours retourne une telle entrée lors d'un re-parcours ou d'un retour arrière, alors même qu'il ne l'a pas retourné lors du parcours initial. À l'identique, une suppression concurrente peut être, ou non, visible dans les résultats d'un parcours. Il est primordial qu'insertions et suppressions ne conduisent pas le parcours à oublier ou dupliquer des entrées qui ne sont pas elles-même insérées ou supprimées.

amgetmulti peut être utilisé à la place de amgettuple pour un parcours d'index. Cela permet de récupérer plusieurs lignes par appel. Cette méthode peut s'avérer notablement plus efficace que amgettuple parce qu'elle permet d'éviter les cycles de verrouillage/déverrouillage à l'intérieur de la méthode d'accès. En principe, amgetmulti a les mêmes effets que des appels répétés à amgettuple, mais plusieurs restrictions ont été imposées pour simplifier la procédure. En premier lieu, amgetmulti ne prend pas d'argument direction, et de ce fait, ne supporte ni parcours inverse ni changement de direction au sein d'un parcours. La méthode d'accès n'a pas non plus à supporter le marquage et la restauration des positions de parcours lors d'un parcours amgetmulti. (Ces restrictions sont minimes, car l'utilisation de ces fonctionnalités lors d'un parcours amgetmulti s'avère difficile : l'ajustement du tampon de la liste des TIDs de l'appelant est complexe). Enfin, amgetmulti ne garantit pas le verrouillage des lignes renvoyées, avec les implications précisées dans Section 50.4, « Considérations sur le verrouillage d'index ».