Chaque méthode d'accès à l'index est décrite par une ligne dans le catalogue système pg_am (voir Section 42.3, « pg_am »). Le contenu principal d'une ligne de pg_am est constitué de références à des entrées de pg_proc identifiant les fonctions d'accès à l'index fournis par la méthode d'accès. Les API pour ces fonctions sont définies plus tard dans ce chapitre. De plus, la ligne de pg_am spécifie quelques propriétés fixes de la méthode d'accès, comme le support des index à plusieurs colonnes. Il n'existe pas de support spécial pour la création ou la suppression d'entrées dans pg_am ; toute personne capable d'écrire une nouvelle méthode d'accès est supposée assez compétente pour insérer une ligne appropriée elle-même.

Pour être utile, une méthode d'accès à l'index doit aussi avoir une ou plusieurs classes d'opérateur définies dans pg_opclass, pg_amop et pg_amproc. Ces entrées autorisent le planificateur à déterminer le type de qualification des requêtes pouvant être utilisé avec les index de cette méthode d'accès. Les classes d'opérateurs sont décrites dans Section 32.14, « Interfacer des extensions d'index », qui est un élément requis pour comprendre ce chapitre.

Un index individuel est défini par une entrée dans pg_class le définissant comme une relation physique, et une entrée dans pg_index affichant le contenu logique de l'index -- c'est-à-dire des colonnes d'index qu'il a et de la sémantique de ces colonnes, de la façon dont elles sont récupérées par les classes d'opérateur associées. Les colonnes de l'index (valeurs clés) peuvent être soit des colonnes simples de la table sous-jacente soit des expressions sur les lignes de la table. Habituellement, la méthode d'accès à l'index n'a aucun intérêt dans l'emplacement d'où provient les valeurs clés de l'index (ce sont toujours des valeurs clés pré-traitées) mais il sera très intéressé dans les informations de la classe d'opérateur dans pg_index. Ces entrées de catalogue peuvent être accédées car elles font partie de la structure de données de Relation qui est passée dans toutes les opérations de l'index.

Certaines des colonnes d'options de pg_am ont des obligations peu évidentes. Les besoins de amcanunique sont discutés dans Section 48.5, « Vérification de l'unicité de l'index », et ceux de amconcurrent dans Section 48.4, « Considérations pour le verrouillage d'index ». L'option amcanmulticol assure que la méthode d'accès supporte les index multicolonnes alors que amoptionalkey assure qu'il fera des parcours où aucune clause indexable de restriction n'est donnée pour la première colonne de l'index. Quand amcanmulticol est faux, amoptionalkey indique essentiellement si la méthode d'accès autorise les parcours complets de l'index sans clause de restriction. Les méthodes d'accès qui supportent plusieurs colonnes d'index doivent supporter les parcours omettant les restrictions d'une ou de toutes les colonnes suivant la première ; néanmoins, elles sont autorisées à réclamer quelque restrictions pour apparaître dès la première colonne de l'index, et ceci est signalé en initialisant amoptionalkey à faux. amindexnulls assure que les index de l'entrée sont créés pour les valeurs clés NULL. Comme la plupart des opérateurs indexables sont stricts et, du coup, ne peuvent pas renvoyer TRUE pour des entrées NULL, il est à première vue attratif de ne pas stocker les entrées d'index pour les valeurs NULL : de toute façon, elles ne peuvent pas être renvoyées par un parcours d'index. Néanmoins, cet argument échoue quand un parcours d'index n'a pas de clause de restriction pour une colonne d'index donnée. En pratique, cela signifie que les index dont amoptionalkey vaut true doivent indexer les valeurs NULL car le planificateur pourrait décider d'utiliser un tel index sans clés parcourus. Une restriction relative est qu'une méthode d'accès à l'index qui supporte plusieurs colonnes d'index doit supporter l'indexage des valeurs NULL dans les colonnes suivant la première car le planificateur supposera que l'index peut être utilisé pour les requêtes qui ne restreignent pas ces colonnes. Par exemple, considérez un index sur (a,b) et une requête avec WHERE a = 4. Le système supposera que l'index peut être utilisé pour les lignes avec a = 4, ce qui est mauvais si l'index omet les lignes où b est null. Néanmoins, il est correct d'omettre les lignes où la première colonne indexée est NULL (GiST le fait actuellement). Du coup, amindexnulls doit valoir true seulement si la méthode d'accès à l'index indexe toutes les lignes, ceci incluant les combinaisons arbitraires des valeurs NULL.