Supondo que se tenha uma tabela semelhante a esta:

CREATE TABLE test1 (
    id integer,
    conteudo varchar
);

e a aplicação execute muitas consultas da forma:

SELECT conteudo FROM test1 WHERE id = constante;

Sem uma preparação prévia, o sistema teria que varrer toda a tabela test1, linha por linha, para encontrar todas as entradas correspondentes. Se houvesse muitas linhas em test1, e fossem retornadas por esta consulta apenas algumas linhas (talvez zero, ou apenas uma), este seria claramente um método ineficiente. Mas se o sistema estiver instruído a manter um índice na coluna id, poderia ser usado um método mais eficiente para localizar as linhas correspondentes. Por exemplo, poderia ser necessário caminhar apenas por alguns níveis em uma árvore de procura.

Uma abordagem semelhante é usada na maioria dos livros que não são de ficção: termos e conceitos frequentemente consultados pelos leitores são reunidos em um índice alfabético no final do livro. O leitor interessado pode varrer o índice de forma relativamente rápida, e ir direto para a(s) página(s) apropriada(s), em vez de ter que ler o livro inteiro para encontrar o material de interesse. Assim como é tarefa do autor antecipar os itens que os leitores provavelmente vão procurar, é tarefa do programador de banco de dados prever quais índices serão úteis.

Pode ser usado o seguinte comando para criar um índice na coluna id,:

CREATE INDEX test1_id_index ON test1 (id);

O nome test1_id_index pode ser escolhido livremente, mas deve ser escolhido algo que permita lembrar mais tarde para que serve o índice.

Para remover um índice, é usado o comando DROP INDEX. Os índices podem ser adicionados e removidos das tabelas a qualquer

Depois que o índice é criado, não será necessária nenhuma intervenção adicional: o sistema atualizará o índice quando a tabela for modificada, e usará o índice nas consultas quando achar ser mais eficiente que a varredura sequencial da tabela. Mas talvez seja necessário executar o comando ANALYZE regularmente para atualizar as estatísticas, e permitir que o planejador de consultas tome decisões adequadas. Veja o Capítulo 14 para obter informações sobre como descobrir se um índice é usado, e “quando e por que” o planejador pode decidir não usar um índice.

Os índices também podem beneficiar os comandos UPDATE e DELETE com condições de procura. Além disso, os índices podem ser usados em procuras de junção. Assim, um índice definido em uma coluna que faz parte de uma condição de junção também pode acelerar muito as consultas com junções.

In general, PostgreSQL indexes can be used to optimize queries that contain one or more WHERE or JOIN clauses of the form Em geral, os índices do PostgreSQL podem ser usados ​​para otimizar consultas que contenham uma ou mais cláusulas WHERE ou JOIN do tipo

coluna-indexada operador-indexável valor-de-comparação

Aqui, a coluna-indexada é qualquer coluna ou expressão na qual o índice foi definido. O operador-indexável é um operador que é membro da classe de operadores do índice da coluna indexada. (Mais detalhes sobre isto aparecem abaixo.) E o valor-de-comparação pode ser qualquer expressão que não seja volátil e não faça referência à tabela do índice.

Em alguns casos, o planejador de consultas pode extrair uma cláusula indexável deste formato de outra construção SQL. Um exemplo simples seria se a cláusula original fosse

valor-de-comparação operador coluna-indexada

então ela poderá ser transformada em um formato indexável se o operador original tiver um operador comutador que seja membro da classe de operadores do índice.

Criar um índice em uma tabela grande pode levar muito tempo. Por padrão, o PostgreSQL permite que ocorram leituras (instruções SELECT) na tabela em paralelo com a criação do índice, mas a escrita (instruções INSERT, UPDATE e DELETE) são bloqueadas até que a construção do índice esteja concluída. Em ambientes de produção, este bloqueio é geralmente inaceitável. É possível permitir que ocorram escritas em paralelo com a criação do índice, mas há várias ressalvas a serem observadas — para obter mais informações sobre este assunto, veja Building Indexes Concurrently.

Após a criação do índice, o sistema deverá mantê-lo sincronizado com a tabela. Isto adiciona sobrecarga às operações de manipulação de dados. Os índices também podem impedir a criação de heap-only tuples. Portanto, os índices que raramente, ou nunca, são usados em consultas devem ser removidos.