Uma varredura de índice único pode usar apenas cláusulas de consulta que usam as colunas do índice com operadores de sua classe de operadores, e são unidas com AND. Por exemplo, dado um índice em (a, b), uma condição de consulta WHERE a = 5 AND b = 6 pode usar o índice, mas uma consulta WHERE a = 5 OR b = 6 não pode usar o índice diretamente.

Felizmente, o PostgreSQL consegue combinar vários índices (incluindo vários usos do mesmo índice), para lidar com casos que não podem ser resolvidos por varreduras de índice único. O sistema pode formar condições AND e OR através de várias varreduras de índice. Por exemplo, uma consulta como WHERE x = 42 OR x = 47 OR x = 53 OR x = 99 pode ser dividida em quatro varreduras separadas de um índice em x, com cada varredura usando uma das cláusulas da consulta. Os resultados destas varreduras são então combinados usando OR para produzir o resultado. Outro exemplo, se houver índices separados em x e y, uma possível resolução de uma consulta como WHERE x = 5 AND y = 6 seria usar cada índice com a cláusula de consulta apropriada e, depois, combinar os diferentes resultados dos índices usando AND para identificar as linhas do resultado.

Para combinar vários índices, o sistema varre cada índice necessário e prepara um bitmap na memória que fornece a localização das linhas da tabela que correspondem às condições do índice. Os bitmaps são depois combinados usando AND e OR, conforme seja necessário para a consulta. Finalmente, as linhas reais da tabela são acessadas e retornadas. As linhas da tabela são acessadas na ordem física, porque é assim que o bitmap é criado; isto significa que a ordem dos índices originais é perdida, portanto, será necessária uma etapa de classificação separada se a consulta incluir a cláusula ORDER BY. Por este motivo, e por que cada varredura de índice adicional acrescenta tempo extra, o planejador às vezes opta por usar uma varredura de índice único, mesmo havendo índices adicionais disponíveis que também poderiam ter sido usados.

Em todas as aplicações, exceto nas mais simples, existem várias combinações de índices que podem ser úteis, e o desenvolvedor do banco de dados deve fazer escolhas para decidir quais índices oferecer. Às vezes, os índices multicoluna são melhores, mas às vezes é melhor criar índices separados e contar com o recurso de combinação de índices. Por exemplo, se a carga de trabalho incluir uma combinação de consultas que envolvem às vezes apenas a coluna x, às vezes apenas a coluna y, e às vezes as duas colunas, pode-se optar por criar dois índices separados em x e y, contando com a combinação de índices para processar as consultas que usam as duas colunas. Também pode ser criado um índice multicoluna em (x, y). Este índice normalmente seria mais eficiente que a combinação de índices para consultas envolvendo as duas colunas, mas conforme discutido na Seção 11.3, reria menos útil para consultas que envolvam apenas y. O quanto será útil irá dependerá da eficácia da otimização da varredura de saltos do índice B-tree; Se x não tiver mais do que algumas centenas de valores distintos, a varredura de salto fará com que as procuras por valores específicos de y sejam executadas de forma razoavelmente eficiente. Uma combinação de um índice de múltiplas colunas em (x, y) e um índice separado em y também pode funcionar razoavelmente bem. Para consultas envolvendo apenas x, o índice de múltiplas colunas pode ser usado, embora seja maior e, portanto, mais lento do que um índice apenas em x. A última alternativa seria criar os três índices, mas isto provavelmente só será razoável se a tabela for procurada com muito mais frequência do que atualizada e se os três tipos de consulta forem comuns. Se um dos tipos de consulta for muito menos comum do que os outros, você provavelmente se contentaria em criar apenas os dois índices que melhor correspondem aos tipos comuns.