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 méthode d'accès peut indiquer que l'index est à perte ou nécessite une vérification pour une requête particulière ; 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 les conditions de l'index au tuple pour vérifier s'il doit bien effectivement être retenu. Si l'option de vérification n'est pas indiquée, le parcours d'index doit renvoyer exactement l'ensemble d'entrées correspondantes.
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. Il existe en fait deux façons différentes permettant à une méthode d'accès de fournir une sortie triée :
Les méthodes d'accès qui renvoient toujours les entrées dans l'ordre naturel (comme les B-tree) doivent configurer pg_am.amcanorder à true. Actuellement, ces méthodes d'accès doivent utiliser des nombres de stratégie compatibles avec les B-tree pour les opérateurs d'égalité et de tri.
Les méthodes d'accès qui supportent les opérateurs de tri doivent configurer pg_am.amcanorderbyop à true. Ceci indique que l'index est capable de renvoyer les entrées dans un ordre satisfaisant ORDER BY clé_index opérateur constante. Les modificateurs de parcours de cette forme peuvent être passés à amrescan comme décrits précédemment previously.
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 initialise amcanorder à true.) 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. (Mais si pg_am.amcanbackward vaut false, tous les appels suivants auront la même direction que le premier.)
Les méthodes d'accès qui supportent les parcours ordonnés doivent supporter le « marquage » d'une position dans un parcours pour retourner plus tard à la position marquée. La même position pourrait être restaurée plusieurs fois. Néanmoins, seule une position par parcours a besoin d'être conservée en mémoire ; un nouvel appel à ammarkpos surcharge la position anciennement marquée. Une méthode d'accès qui ne supporte pas les parcours ordonnés doit quand même fournir les fonctions de marquage et de restauration dans pg_am, mais il est suffisant de leur faire renvoyer des erreurs si les fonctions sont appelées.
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.
Si l'index stocke les valeurs originales des données indexées (et pas une représentation à perte des données), il est utile de supporter les parcours d'index seul, pour lesquels l'index renvoie la donnée réelle et non pas seulement le TID de la ligne dans la table. Ceci va seulement fonctionner si la carte de visibilité montre que le TID est sur une page dont toutes les lignes sont visibles par toutes les transactions en cours. Sinon, la ligne de la table doit être visitée de toute façon pour s'assurer de sa visibilité pour la transaction en cours. Mais cela ne concerne pas la méthode d'accès.
amgetbitmap peut être utilisé à la place de amgettuple pour un parcours d'index. Cela permet de récupérer toutes les lignes en un 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, amgetbitmap 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, amgetbitmap renvoie toutes les lignes en une fois et le marquage ou la restauration des positions de parcours n'est pas supporté. Ensuite, les lignes sont renvoyées dans un bitmap qui n'a pas d'ordre spécifique, ce qui explique pourquoi amgetbitmap ne prend pas de direction en argument. (Les opérateurs de tri ne seront jamais fournis pour un tel parcours.) De plus, il n'existe aucune disposition pour les parcours d'index seul avec amgetbitmap car il n'y a aucun moyen de renvoyer le contenu des lignes d'index. Enfin, amgetbitmap ne garantit pas le verrouillage des lignes renvoyées, avec les implications précisées dans Section 52.4, « Considérations sur le verrouillage d'index ».
Notez qu'il est permis à une méthode d'accès d'implanter seulement amgetbitmap et pas amgettuple, ou vice versa, si son implantation interne ne convient qu'à une seule des API.
Fonctions de la méthode
d'accès aux index
