> com a execução caindo para 765 ms quando em cache. Me surpreende o fato de > os join alterados não serem na tabela compras, e agora o plano usar o > índice desejado em compras. Não caberia aqui alguma melhoria no algorítimo > do otimizador? >
O uso de índices com LEFT JOIN é um problema conhecido, não apenas no Postgres. Veja uma melhoria em relação a isto nos release notes do 9.1 em E.7.3.1.1. Performance: http://www.postgresql.org/docs/9.2/static/release-9-1.html > > De qualquer forma, obrigado a todos pela ajuda. Foi esclarecedor pra mim e > pra lista. > Cara, faz o que o Euler falou, manda o EXPLAIN ANALYZE. Vai permitir uma avaliação mais consistente. Algumas observações até aqui: * Vale sempre a pena lembrar, antes de tudo rode um ANALYZE em todas as tabelas envolvidas. Sei que você já deve ter feito isso, mas eu mesmo esqueço de vez em quando... * Muito LEFT JOIN em cascata é realmente um problema. Você pode trocar os mais caros por um UNION, onde você fazer um INNER JOIN em um e no outro no outro faz um WHERE NOT EXISTS. * Você pode ter uma NFE sem ter uma compra e uma venda? * Uma informação relevante é o volume de registros entre as tabelas envolvidas; * Algumas tabelas aparecem mais de uma vez. Parecem ser tabelas pequenas, mas a modelagem ficou um pouco obscura para mim. * A tabela COMPRAS tem mais de 10 índices, é isso mesmo? Verificou se todos estão sendo utilizados? * Eu gosto um pouco de usar o EXPLAIN do PGADMIN III. Em alguns momentos a visualização gráfica torna mais fácil de ver os gargalos dentro de um EXPLAIN muito grande. Por enquanto é isso. Vamos aguardar o EXPLAIN ANALYZE, ok? []s -- Atenciosamente, Fábio Telles Rodriguez blog: http:// <http://www.midstorm.org/~telles/>http://tellesr.wordpress.com e-mail / gtalk / MSN: [email protected] Skype: fabio_telles
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
