O autovacuum está habilitado? Experimente fazer um VACUUM ANALYZE
tb_produto_loja e depois teste os dois plano novamente. Se a diferença dos
números de rows *não* se aproximar, apresente os planos novamente.
O autovaccum estava desabilitado, fiz o VACUUM FULL ANALYZE em toda base e
um REINDEX
Em 5 de março de 2012 08:33, Fábio Naspolini fabionaspol...@gmail.comescreveu:
O autovacuum está habilitado? Experimente fazer um VACUUM ANALYZE
tb_produto_loja e depois teste os dois plano novamente. Se a diferença
dos
números de rows *não* se aproximar, apresente os planos novamente.
O
Só por curiosidade, qual a diferença do de tempo de execução do SQL
original com o compilado (com os casts) agora, depois do VACUUM?
Agora depois do vacuum ficou instantâneo os 2 sql's, segue ae os 2 planos
de execução depois do vacuum.
Em termos de tempo, os sqls sem cast eram praticamente
Em 5 de março de 2012 09:30, Fábio Naspolini fabionaspol...@gmail.comescreveu:
Só por curiosidade, qual a diferença do de tempo de execução do SQL
original com o compilado (com os casts) agora, depois do VACUUM?
Agora depois do vacuum ficou instantâneo os 2 sql's, segue ae os 2 planos
de
Conclusão: Sempre depois de fazer um retore faça um vacuum também.
Realmente fez muita diferença.
Ótima thread, uma boa lição!
Deixo outra lição: JAMAIS desligar o autovacuum. Ele cuida disso pra você.
Fiz gente do mundo inteiro prometer isso numa palestra que dei na PgCon 2010 :)
[]s
Não sabia que CASTS deixava querys mais lentas. No máximo a diferença é
imperceptível, ou estou errado?
Nesse SQL abaixo fez muita diferença o cast
Cadê os planos de execução com a visão e sem ela provando o ocorrido?
Infelizmente não tenho salvo a melhor situação pra representar este caso,
Boa tarde,
meu problema é o seguinte, depois de compilar uma view toda identada e
organizada certinha, o postgre desorganiza todo o fonte, coloca um monte de
cast desnecessário e a performance diminui.
Trabalho atualmente com o PG 9.1 e já sofri algumas vezes por conta disso,
tive uma situação
Em 1 de março de 2012 16:45, Fábio Naspolini fabionaspol...@gmail.comescreveu:
corte
Gostaria de saber se há como desativar esta reorganização de fontes feita
automaticamente pelo postgre?
Tanto pelo motivo de ficar lento as vezes quanto pela dificuldade em dar
manutenção em view's mais
Gostaria de saber se há como desativar esta reorganização de fontes feita
automaticamente pelo postgre?
Tanto pelo motivo de ficar lento as vezes quanto pela dificuldade em dar
manutenção em view's mais complexas que existem no sistema.
Não sabia que CASTS deixava querys mais lentas. No
Eu coloco os fontes das views sob controle de versão para não sofrer com
esta desorganização.
Nunca percebi, no entanto, nenhuma queda de performance -- apenas de
legibilidade.
Em 1 de março de 2012 16:45, Fábio Naspolini fabionaspol...@gmail.comescreveu:
Boa tarde,
meu problema é o seguinte,
On 01-03-2012 16:45, Fábio Naspolini wrote:
Trabalho atualmente com o PG 9.1 e já sofri algumas vezes por conta disso,
tive uma situação certa vez em que o postgre colocou um cast numa comparação
que fez um SQL de poucos segundos demorar mais de 10 minutos (Isso porque
cancelei a execução e
11 matches
Mail list logo
