Embora no PostgreSQL os índices não precisem de manutenção ou ajuste, ainda assim é importante verificar quais índices são realmente usados pela carga de trabalho das consultas da vida real. O exame do uso do índice por uma consulta individual é feito usando o comando EXPLAIN; sua aplicação para este fim está mostrada na Seção 14.1. Também é possível reunir estatísticas gerais sobre o uso de índice em um servidor em funcionamento, conforme descrito na Seção 27.2.
É difícil formular um procedimento geral para determinar quais índices devem ser criados. Há vários casos típicos mostrados nos exemplos ao longo das seções anteriores. Muitas vezes há necessidade de uma boa dose de experimentação. O resto desta seção dá algumas dicas práticas:
Sempre execute o comando ANALYZE primeiro.
Este comando coleta estatísticas sobre a distribuição dos valores
na tabela.
Estas informações são necessárias para estimar o número de linhas
retornadas por uma consulta.
O planejador precisa disto para atribuir custos realistas a cada
plano de consulta possível.
Na ausência de estatísticas reais, são assumidos alguns valores
padrão, que provavelmente são inadequados.
Examinar o uso do índice de uma aplicação sem executar o comando
ANALYZE antes é, portanto, uma causa perdida.
Veja a Seção 24.1.3 e a
Seção 24.1.6 para obter mais informações.
Use dados reais para os experimentos. Usar dados de teste para configurar índices informará quais índices são necessários para os dados de teste, mas isso é tudo.
É notadamente fatal usar conjuntos de dados de teste muito pequenos. Embora selecionar 1.000 de 100.000 linhas possa ser um candidato para um índice, selecionar 1 de 100 linhas dificilmente será, porque as 100 linhas provavelmente cabem em uma única página de disco, não havendo plano que possa superar a busca sequencial em apenas uma página de disco.
Também tenha cuidado ao criar dados de teste, o que geralmente é inevitável quando a aplicação ainda não está em produção. Valores que são muito semelhantes, completamente aleatórios, ou inseridos em ordem classificada, vão distorcer as estatísticas da distribuição que os dados reais teriam.
Quando índices não são usados pode ser útil para os testes forçar
seu uso. Existem parâmetros de tempo de execução que podem desativar
vários tipos de planos
(veja a Seção 19.7.1).
Por exemplo, desativar varreduras sequenciais
(enable_seqscan) e junções de laço aninhado
(enable_nestloop), que são os planos mais básicos,
vão forçar o sistema a usar um plano diferente.
Se o sistema ainda assim escolher a varredura sequencial, ou uma
junção de laço aninhado, provavelmente há uma razão mais fundamental
pela qual o índice não está sendo usado;
por exemplo, a condição da consulta não corresponde ao índice.
(Que tipo de consulta pode usar que tipo de índice está explicado
nas seções anteriores.)
Se forçar o uso do índice faz com que o índice seja usado,
então existem duas possibilidades:
ou o sistema está certo, e o uso do índice não é apropriado,
ou as estimativas de custo dos planos de consulta não refletem
a realidade.
Portanto, a consulta deve ser cronometrada com e sem o uso de índices.
O comando EXPLAIN ANALYZE pode ser útil nesta
situação.
Se as estimativas de custo se revelarem erradas, há novamente duas possibilidades. O custo total é calculado a partir dos custos por linha de cada nó do plano vezes a estimativa de seletividade do nó do plano. Os custos estimados para os nós do plano podem ser ajustados por meio de parâmetros de tempo de execução (descritos na Seção 19.7.2). Uma estimativa de seletividade imprecisa se deve a estatísticas insuficientes. Pode ser possível melhorar esta situação ajustando os parâmetros de coleta de estatísticas (veja ALTER TABLE).
Se não for possível ajustar os custos para se tornarem mais apropriados, talvez seja necessário forçar o uso do índice explicitamente. Também é possível entrar em contato com os desenvolvedores do PostgreSQL para examinar o problema.