Em 14 de novembro de 2010 22:12, Euler Taveira de Oliveira < [email protected]> escreveu:
> Particularmente acho esses testes muito artificiais. Quem me garante que os > dados vão estar na cache toda vez que aquela consulta for executada? E se > os > dados não estiverem na cache? Assim, sugiro que monte um teste real com > consultas do seu sistema. Por quê? Nem sempre os tempos obtidos com esses > testes isolados (com ou sem cache) apresentarão o plano e o tempo *real* da > consulta durante a execução no sistema. > > Isso que o Euler mencionou já sofri na pele (várias vezes), e a forma mais adequada que encontrei de testar foi sim com queries do meu sistema, então automatizei o ciclo: 1) Reiniciar PostgreSQL 2) Apagar Estatisticas (um DELETE na pg_statistic resolve) 3) Analyze nas Tabelas Envolvidas na Query (todas mesmo, se tiver funcoes tem que ver que tabelas a mesma usa) 4) Limpar cache do SO (sync ; echo 3 > /proc/sys/vm/drop_caches) 5) Explain Analyze na(s) Query(ies) "problemática(s)" Com isso sabe o que eu detectei... problema no meu modelo de dados... então com uma pequena refatoração obtivemos excelentes resultados... lembre-se que tunning não é apenas no banco, a maior parte dos problemas de desempenho não estão no banco e/ou sistema operacional e sim nas suas estruturas de dados e queries. -- Fabrízio de Royes Mello >> Blog sobre TI: http://fabriziomello.blogspot.com >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
