2011/11/12 Eduardo Santos <[email protected]>: > Pessoal, > Estava com alguns problemas de lock e decidi atualizar minha versão do > PostgreSQL da 8.2 para a 8.4, onde muitos avanços foram feitos nesse campo. > Contudo, para minha surpresa, a performance caiu drasticamente. O curioso é > que as máquinas físicas são idênticas fisicamente e mantive exatamente os > mesmos parâmetros de configuração para o PostgreSQL. Para se ter uma ideia > da queda, vou mostrar a saída do EXPLAIN ANALYZE para a mesma consulta nos > diferentes bancos. > Consulta no PostgreSQL 8.2 > Sort (cost=1029.63..1029.71 rows=33 width=42) (actual > time=3895.353..3895.361 rows=67 loops=1) <corte> ,/corte> > Total runtime: 3895.939 ms > (27 registros) > > Consulta no PostgreSQL 8.4 > Sort (cost=3616469.97..3616470.15 rows=72 width=39) (actual > time=95704.475..95704.486 rows=67 loops=1) <corte> </corte> > Total runtime: 95704.632 ms > (26 registros) > > As diferenças entre as decisões tomadas pelo otimizador são tão absurdas que > não sei nem por onde começar. > Será que alguém pode me dar uma luz? > --
Pelos números apresentados tudo indica que suas estatísticas estavam atualizadas o que levou o planejador a optar por caminhos ineficientes. Veja por exemplo: Nested Loop (cost=0.00..982907.73 rows=397639583 width=4) (actual time=0.102..1117.157 rows=1396734 loops=67) ele estimou que existiriam 397.639.583 linhas quando, na realidade, existiam 1.396.734 linhas. Rode novamente sua consulta com as estatísticas atualizadas e avalie o resultado. A versão que você está utilizando é a 8.4.9? Osvaldo _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
