Fabrizio Mello - Pessoal escreveu: > Pessoal, > > O amigo Mozart expressou bem o *sentimento de indignação* quanto a > esse mistério que são as configurações para *tunning* do nosso > elefantinho. > Tuning é uma arte muitas vezes incompreendida. Ter paciência e bom senso é essencial, vou tentar ajudar aqui me baseando nos testes e experiências que tive.
> > Dando continuidade a esse *dilema* vamos a resultados práticos que > obtive e, como iremos ver, continuam estranhos... > > > Tenho as seguintes tabelas envolvidas no teste: > - NotaFiscal ( 2.162.878 registros) > - NotaItem (28.041.370 registros) > - Produto ( 41.911 registros) > Tua base é de pequena pra média, acho que dá pra melhorar bastante esses tempos. > <corta> > > 6) Estatisticas = 0 (desabilitado) nas Colunas das Tabelas NotaFiscal > e NotaItem, mas com uma pequena modificação no SELECT: > "DataMovimentoNota" between '2008-04-01' and '2008-04-30' > (Selecionado o Mes Inteiro) > Linhas Estimadas: 13 > Linhas Retornadas: 1.266.367 > Tempo de Execução: 84195.499 ms *MENOR TEMPO DE TODOS* > > Obs: Agora uma surpresa... ~84seg para retornar 1.266.367, muito menos > que os ~13min q levou com as estatisticas setadas pra 1000 > Acho que você deveria esquecer um pouco o parâmetro de estatísticas da tabela, e voltar a ele assim que a casa estiver arrumada. Sobre o que o Euler disse do cache do SO, ele está armazenando o resultado das querys e está influenciando nesse resultado. Para zerar o cache, não basta reiniciar o PG, pare o serviço e digite: # echo 3 > /proc/sys/vm/drop_caches Inicie o banco novamente, mude apenas um parâmetro de cada vez, e repita o analyze. Bom, agora falando sobre o que eu considero mais importante: é muito difícil você conseguir obter bons resultados rodando em um notebook, com apenas 800Mhz por core. Não sei qual é o teu ambiente de produção, mas o ideal seria se você conseguisse testar em um ambiente parecido. A velocidade do clock e o tamanho do cache (quase inexistente neste notebook) influencia bastante em joins e sorts. Mande pra gente como é o teu ambiente de produção, inclusive se existem partições e RAIDs. Neste ambiente de testes, com um HD fazendo tudo, fica meio difícil ter ganhos maiores. Sobre o postgresql.conf, habilite todos os planos do planejador. Seq scans são muito úteis para filtros e buscas em tabelas pequenas. Não tente "enganar" o planejador, tente fazer ele acertar o máximo nas estatísticas; não faz sentido que uma query rode mais rápido se o planejador estiver errado. É apenas uma questão de bom senso, *muita* gente boa trabalhou em cima de otimizações para o planejador. Ele é mais esperto do que você ;) Veja também se a versão do PG é a mesma nos ambientes de teste e produção. Se for, atualize para a última do 8.2. PS: Sobre os auto-tunnings, apesar do enorme esforço da comunidade, creio que ainda estamos engatinhando. Nenhuma das propostas foi pra frente, que eu saiba ... -- []´s, ACV _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
