Euler Taveira de Oliveira escreveu: > Os seus testes não são válidos pois as consultas subsequentes vão se > beneficiar da cache do SO. Antes de cada teste, execute o comando (sync > && echo 3 > /proc/sys/vm/drop_caches) para remover a cache do SO. Sempre > execute o ANALYZE nas tabelas envolvidas antes das consultas. Você não > precisa do DELETE FROM pg_statistic (o stats_reset_on_server_start = on > já faz isso). Além disso, a sua configuração básica está inadequada para > o volume de dados que está manuseando. Experimente, aumentar alguns > valores para que pelo menos o PostgreSQL não perca *tanto* tempo usando > o disco como memória secundária. >
Um restart no processo do PostgreSQL não resolve a questão do Cache??? Cada caso de teste eu executava da seguinte forma: 1) Reiniciar PostgreSQL 2) Setar Estatisticas para o Teste nas tabelas necessárias 3) Delete From pg_statistic 4) Analyze nas tabelas em que as estatisticas foram alteradas 5) Explain Analyze na Query Sobre o "stats_reset_on_server_start" eu havia alterado ele na minha configuração, só esqueci de eliminar o Passo 3 do teste. Também acredito, e muito, que a configuração esteja inadequada pro volume de dados, mas quais parametros vc recomenda aumentar: shared_buffers, work_mem, effective_cache_size ???? (Vou fazer alguns testes) > Outra coisa que percebi é que você desabilitou o seqscan e o tidscan. > Por quê? Se a idéia é avaliar os planos e estatísticas dos mesmos então > você tem que fornecer todas ferramentas ao SGBD. > > Faça o que sugeri acima e repita os testes. > Vou fazer isso... > cache do SO? > O restart no processo do PostgreSQL não elimina esse Cache???? > Acho que o seu problema é outro... > É justamente o que preciso de ajuda para descobrir e entender esse *outro* problema? > Você não entendeu o que eu expliquei. Releia a discussão. O tempo de > planejamento não pode ser significativo em relação ao tempo de execução. > > Entendi sim o que dissestes, mas de repente não soube me expressar... A questão é que tentei valores das estatisticas justamente pro PostgreSQL não despender tempo desnecessário com o planejamento (verifiquei colunas estimadas e retornadas como recomendastes)... o caso é que o valor que melhor se ajustou foi 1000, entretando alterando a query pra abranger um volume maior de dados o resultado em relação a desativacao das estatisticas foi absurdo (~85seg para ~13min)... é considerável a diferença... por isso comentei que o planejador poderia estar *atrapalhando*... é claro que isso foi só uma forma de se expressar, pois é óbvio que esses recursos são pra ajudar, mas não estou conseguindo achar um ponto ótimo para que isso aconteça... Até agora o que pude detectar é que com as estatisticas fica muito ruim e sem elas fica legal... por isso peço um *help* a vcs pois *tem coisa errada*... > PS> quando for enviar o postgresql.conf, envie somente os parâmetros que > forem relevantes ou o que é diferente do arquivo padrão. Isso evita que > algum moderador tenha que liberar a sua mensagem por causa do tamanho do > e-mail. > Peço desculpas... foi mal mesmo... numa próxima vez farei como sugeres... Cordialmente, -- Fabrízio de Royes Mello Coordenador Desenvolvimento de Software [EMAIL PROTECTED] DBSeller Informática Ltda. - http://www.dbseller.com.br (51) 3076-5101 _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
