Un parcours d'index simple utilise les clauses de la requête qui utilisent les colonnes de l'index avec les opérateurs de sa classe d'opérateur et qui sont joint avec AND. Par exemple, étant donné un index sur (a, b), une condition de requête WHERE a = 5 AND b = 6 pourrait utiliser l'index mais une requête comme WHERE a = 5 OR b = 6 ne pourrait pas utiliser directement l'index.

À partir de la version 8.1, PostgreSQL™ peut combiner plusieurs index (y compris plusieurs utilisations du même index) pour gérer les cas qui ne peuvent pas être implémentés avec des parcours d'index simples. Le système peut former des conditions AND et OR au travers de plusieurs parcours d'index. Par exemple, une requête comme WHERE x = 42 OR x = 47 OR x = 53 OR x = 99 pourrait être divisée en quatre parcours séparés d'un index sur x, chaque parcours utilisant une des clauses de la requête. Les résultats de ces parcours sont alors assemblés avec un OR pour produire le résultat. Un autre exemple est que, si nous avons des index séparés sur x et y, une implémentation possible d'une requête comme WHERE x = 5 AND y = 6 est d'utiliser chaque index avec la clause de la requête appropriée et d'assembler les différents résultats avec un AND pour identifier les lignes résultantes.

Pour combiner plusieurs index, le système parcourt chaque index nécessaire et prépare un bitmap en mémoire en donnant l'emplacement des lignes de table qui sont rapportées comme correspondant aux conditions de l'index. Les bitmaps sont ensuite assemblés avec des opérateurs AND ou OR suivant les besoins de la requête. Enfin, les lignes réelles de la table sont visitées et renvoyées. Elles sont visitées dans l'ordre physique parce c'est ainsi que le bitmap est créé ; cela signifie que tout ordre des index originaux est perdu et que, du coup, une étape de tri séparée sera nécessaire si la requête comprend une clause ORDER BY. Pour cette raison, et parce que chaque parcours d'index supplémentaire ajoute un temps additionnel, le planificateur choisira quelque fois d'utiliser un parcours d'index simple même si des index supplémentaires sont disponibles et auraient aussi pû être utilisés.

Dans toutes les applications un peu compliquées, il existe différentes combinaisons d'index qui pourraient être utiles. Le développeur de la base de données doit faire des concessions pour décider des index à fournir. Quelque fois, des index à colonnes multiples sont préférables mais quelque fois, il est mieux de créer des index séparés et de dépendre de la fonctionnalité des index combinés. Par exemple, si votre temps de travail inclut un mixe des requêtes qui impliquent parfois seulement la colonne x, quelque fois seulement la colonne y et quelque fois les deux colonnes, vous pourriez choisir deux index séparés sur x et y, en vous reposant sur la combinaison d'index pour traiter les requêtes qui utilisent les deux colonnes. Vous pouvez aussi créer un index multicolonne sur (x, y). Cet index serait typiquement plus efficace que la combinaison d'index pour les requêtes impliquant les deux colonnes mais, comme discuté dans la Section 11.3, « Index multicolonnes », il serait pratiquement inutile pour les requêtes impliquant seulement y, donc il ne peut pas être le seul index. Une combinaison de l'index multicolonnes et d'un index séparé sur y serviraient raisonnablement. Pour les requêtes impliquant seulement x, l'index multicolonne pourrait être utilisé bien qu'il soit plus large et donc plus lent qu'un index sur x seul. La dernière alternative est de créer les trois index mais ceci est probablement seulement raisonnable si la table est parcourue bien plus fréquemment qu'elle n'est mise à jour et les trois types de requête sont communs. Si un des types de requête est bien moins courant que les autres, vous devriez probablement en rester à la création des deux seuls index qui correspondront le mieux aux types communs.