Dans un parcours d'index, la responsabilité de la méthode d'accès est de recracher tous les TID de toutes les lignes qu'on lui a dit 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 parente 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é est une des colonnes de l'index et l'opérateur un des
membres de la famille d'opérateurs associée à cette colonne. Un
parcours d'index a entre zéro et plusieurs clés de parcours 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, plus é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 à la ligne pour vérifier si elle doit effectivement être retenue. 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
se contente de transférer 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, avec
WHERE x > 4 AND x > 14
, où x
est une colonne
indexée par 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 des données (comme les B-tree) doivent configurer
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 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écrit précédemment.
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
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 peut ê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 n'a pas besoin de fournir les fonctions
ammarkpos
et amrestrpos
dans sa
structure IndexAmRoutine
; configurez ces
pointeurs à NULL dans ce cas.
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 acceptable qu'une entrée tout juste insérée ne soit pas retournée par un parcours qui l'aurait trouvée si l'entrée avait existé au démarrage du parcours. 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ée lors du parcours initial. De même, 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 insérées ou supprimées.
Si l'index stocke les valeurs originales des données indexées (et pas une représentation à perte), il est utile de supporter les parcours d'index seul, pour lesquels l'index renvoie la donnée réelle et non pas juste le TID de la ligne dans la table. Ceci n'évitera des I/O que 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.
Un parcours d'index peut utiliser amgetbitmap
à la place de
amgettuple
pour
récupérer toutes les lignes en un unique appel. Cette méthode peut s'avérer
nettement 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 non plus 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 60.4.
Notez qu'il est permis à une méthode d'accès d'implémenter seulement
amgetbitmap
et pas amgettuple
, ou
vice versa, si son fonctionnement interne ne convient qu'à une seule des API.