Em 15 de abril de 2011 10:18, Fábio Gibon - Comex System <[email protected]> escreveu: > Olá pessoal, > analisando as views de stat conseguimos identificar índices que não > são utilizados, porém isto ainda não nos diz que esta "não utilização" é > pela aplicação não estar fazendo uso de cláusulas que possam ser atendidas > pelo índice ou pela tabela ser pequena e o otimizador optar por um table > scan. Há como eu diferenciar isto em algum local do dicionário de dados do > banco? > > * provisoriamente adotei um valor x de registros como sendo > permissível/aceitável o table scan, então se o acesso sequencial retornar > mais que este valor eu já "fico de olho" para ver se não tem problema de SQL > mal escrito/erro de modelagem ou regra de negócio "torta". >
Não conheço a fundo o código-fonte do PostgreSQL - mesmo porque entendo muito pouco de C - mas pelo comportamento que vejo em outros bancos de dados, quando uma tabela está quase totalmente em cache e você cria um SQL SELECT que traz quase todos os registros, o otimizador é inteligente o suficiente para saber que um Table Scan é a melhor opção. Eu considero a parte de otimização de consultas a parte mais divertida e prazerosa do trabalho de um DBA. Muitas vezes - quase sempre - é necessário reescrever a consulta para melhorar o tempo de resposta, outras vezes você modifica um ou outro índice, e por aí vai. Existem 1001 maneiras de otimização... invente uma! -- TIAGO J. ADAMI http://www.adamiworks.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
