>> 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 :)
[]
Em 5 de março de 2012 09:30, Fábio Naspolini escreveu:
> > 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 va
> 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 igu
Em 5 de março de 2012 08:33, Fábio Naspolini escreveu:
> > 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 esta
> 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 REINDE
On 02-03-2012 09:42, Fábio Naspolini wrote:
Essa estimativa errada é que está causando a lentidão no plano.
No primeiro plano:
> -> Bitmap Index Scan on
> tb_produto_loja_pkey (cost=0.00..5.12 rows=115 width=0) (actual
> time=3.858..3.858
> 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,
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
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 escreveu:
> Boa tarde,
> meu problema é o seguinte, depois de compilar uma
>
> 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.
Em 1 de março de 2012 16:45, Fábio Naspolini escreveu:
>
>
>
> 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
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 cer
12 matches
Mail list logo
