PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Como entender uma EXPLAIN ANALYSE


Embora não seja tão útil para um plano simples como este, http://explain.depesz.com é realmente útil. Veja http://explain.depesz.com/s/t4fi. Observe a guia "estatísticas" e o menu suspenso "opções".

Pontos a serem observados sobre este plano:

  • A contagem de linhas estimada (183) é razoavelmente comparável à contagem de linhas real (25). Não é centenas de vezes mais, nem é 1. Você está mais interessado em ordens de magnitude quando se trata de estimativas de contagem de linhas ou questões "1 vs não 1". (Você nem precisa de precisão "próximo o suficiente para o trabalho do governo" - "próximo o suficiente para a contabilidade de contratação militar" servirá). A estimativa de seletividade e as estatísticas parecem razoáveis.

  • Está usando o índice parcial de duas colunas fornecido (index scan using index_cars_onsale_on_brand_and_model_name ), portanto, corresponde à condição de índice parcial. Você pode ver isso no Filter: has_auto_gear . A condição de pesquisa de índice também é mostrada.

  • O desempenho da consulta parece razoável, pois a contagem de linhas da tabela significa que o índice é bastante grande, especialmente porque tem mais de duas colunas. As linhas correspondentes serão espalhadas, portanto, é provável que cada linha também exija uma leitura de página separada.

Não vejo nada de errado aqui. Essa consulta provavelmente se beneficiará muito das varreduras somente de índice do PostgreSQL 9.2.

É possível que haja algum inchaço de tabela aqui, mas dado o índice de 2 colunas e o grande número de linhas, o tempo de resposta não é totalmente irracional, especialmente para uma tabela com 170 (!!) colunas que provavelmente cabem relativamente poucas tuplas em cada página. Se você puder arcar com algum tempo de inatividade, tente VACUUM FULL para reorganizar a tabela e reconstruir o índice. Isso bloqueará exclusivamente a tabela por algum tempo enquanto a reconstrói. Se você não puder arcar com o tempo de inatividade, consulte pg_reorg e/ou CREATE INDEX CONCURRENTLY e ALTER INDEX ... RENAME TO .

Você pode encontrar EXPLAIN (ANALYZE, BUFFERS, VERBOSE) mais informativo às vezes, pois pode mostrar acessos de buffer, etc.

Uma opção que pode tornar essa consulta mais rápida (embora corra o risco de retardar um pouco outras consultas) é particionar a tabela em brand e ative constraint_exclusion . Consulte particionamento.