Dans un parcours d'index, la méthode d'accès à l'index est responsable de l'ingurgitation des TID de toutes les lignes indiquées comme correspondant aux clés de parcours. La méthode d'accès n'est réellement impliquée ni dans la récupération de ces lignes à partir de la table parent de l'index ni dans la détermination du passage du test de qualification ou d'autres conditions.

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 classe d'opérateur associée avec cette colonne d'index. Un parcours d'index a aucune ou 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 classe d'opérateur peut indiquée que l'index est à perte pour un opérateur particulier ; ceci implique que le parcours d'index renverra toutes les entrées qui correspondent à la clé de parcours, avec les entrées supplémentaires qui ne correspondent pas. La machinerie du parcours d'index du système principal s'appliquera ensuite cet opérateur pour vérifier s'il doit bien être utilisé. Pour les opérateurs sans perte, le parcours d'index doit renvoyer exactement l'ensemble d'entrées correspondantes cet il n'y aura pas de nouvelle vérification.

Notez qu'il est entièrement à la charge de la méthode d'accès de 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 donnera toutes les clauses WHERE correspondant aux clés d'index et aux classes d'opérateurs, sans analyse sémantique déterminant si elles sont redondantes ou contradictoires. Comme exemple, étant donné WHERE x > 4 AND x > 14 où x est une colonne indexée B-tree, elle est passée à la fonction B-tree amrescan pour 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épendra du supplément dont la méthode d'accès à l'index a besoin pour réduire les clés de parcours en une forme « normalisée ».

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 spécifie BackwardScanDirection, alors l'ensemble d'entrées d'index correspondantes est à parcourir de l'arrière vers l'avant plutôt que dans la direction normale, donc amgettuple doit renvoyer la dernière ligne correspondante dans l'index, plutôt que la première (ceci arrivera seulement pour les méthodes d'accès qui indiquent qu'elles supportent les parcours ordonnés en initialisant pg_am.amorderstrategy à une valeur différente de zéro). Après le premier appel, amgettuple doit être préparé pour continuer le parcours dans une direction à 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 pourrait être restaurée plusieurs fois. Néanmoins, seule une position doit être en mémoire par parcours ; un nouveau appel à ammarkpos surcharge la position marquée précédemment.

La position du parcours et du marquage doivent être conservées de façon cohérente dans le cas d'insertions et de suppressions concurrentes pendant le parcours. Il est considéré correct qu'une entrée tout juste insérée ne soit pas renvoyée par un parcours qui aurait trouvé cette entrée si elle avait existé au moment où le parcours a commencé, ou que le parcours renvoie une telle entrée lors d'un nouveau parcours même si elle n'a pas été renvoyée la première fois. De façon similaire, une suppression concurrente pourrait ou non être réfléchie dans les résultats d'un parcours. Ce qui est important est que les insertions ou suppressions ne causent pas un manque ou un renvoi multiple des entrées qui n'ont pas été insérées ou supprimées (pour un type d'index qui ne configure pas pg_am.amconcurrent, il est suffisant de gérer ces cas pour les insertions et suppressions réalisées par le serveur qui effectue le parcours. Mais quand amconcurrent vaut true, les insertions ou suppressions des autres serveurs doivent aussi être gérées).

Au lieu d'utiliser amgettuple, un parcours d'index peut se faire via amgetmulti pour récupérer différentes lignes par appel. Cela peut être notablement plus efficace que amgettuple parce que cela permet d'éviter les cycles de verrouillage/déverrouillage à l'intérieur de la méthode d'accès. En principe, amgetmulti devrait avoir les mêmes effets que des appels répétés à amgettuple, mais nous imposons plusieurs restrictions pour simplifier la gestion. En premier lieu, amgetmulti ne prend pas d'argument direction. Du coup, il ne supporte ni les parcours inverses ni le changement de direction lors d'un parcours. La méthode d'accès n'a pas besoin de supporter le marquage ou la restauration des positions de parcours lors d'un parcours amgetmulti (ces restrictions ne coûtent rien car il serait difficile d'utiliser ces fonctionnalités y compris dans le cas d'un parcours amgetmulti : ajuster la liste en tampon des TIDs de l'appelant serait complexe). Enfin, amgetmulti ne garantit pas un verrouillage des lignes renvoyées, avec les implications précisées dans Section 48.4, « Considérations pour le verrouillage d'index ».