Respondendo: > Ninguém se interessou e *provou* que aumentando o parâmetro vai trazer > benefício para todos.
Bom, passei um bom tempo expondo, perguntando e esperando descobrir o que é prova suficiente para quem decide. Nessa última mensagem deu para ter uma idéia, por mais que eu discorde que precise disso para decidir algo dessa natureza. > Consultas com: > (i) vários tipos de dados > (ii) várias distribuições desses dados > (iii) número de registros variados (10, 100, 1k, 10k, 100k, 1m, 10m, > 100m, 1b -- acho que é o suficiente) Nem vou entrar no mérito de quanto detalhamento precisaria para chegar em algo que a meu ver justifique alguma conclusão puramente empírica. De qualquer forma obrigado pela informação. Vou ver se providencio algo parecido quando for contatar a lista que você indicou. >> * o caso mais frequente (eu acho que meu caso é), ou > Esses 'achos' é que precisam ser validados... Bom, quando eu souber que critério 'validou' o valor atual, posso até discutir se preciso justificar mais alguma coisa nos meus 'achos'. > VACUUM ANALYZE? Qual a diferença? Nenhuma. Só faço testes depois dele. > [1] http://archives.postgresql.org/pgsql-hackers/2006-09/msg01521.php > [2] http://archives.postgresql.org/pgsql-patches/2007-11/msg00170.php Em [1] não vi nenhuma crítica relevante contra valores altos em estatísticas, muito pelo contrário. Pelo menos, vi sensatez no comentário sobre ter estatísticas consolidadas de várias colunas em versões futuras. Isso sem dúvida trará muito mais benefícios do que mexer em parâmetros (apesar das duas coisas irem muito melhor juntas). Em [2] não achei nada em favor do valor atual, muito pelo contrário. De qualquer forma obrigado pela referência. > mesmo usando 1000 ficou mais rápido sem as estatisticas... Olhando os resultados, nota-se que neste caso o Postgres só escolheu um bom plano quando as estimativas forneceram valores completamente fora da realidade (estimado 13 encontrado 480000). Isso neste caso foi ótimo, mas acho absurdo contar com isso como regra geral. Essa consulta pode até ficar mais rápida sem estatísticas, mas teoricamente é de se esperar que muitas outras consultas serão prejudicadas, enquanto que poucas vão (por puro acaso) se beneficiar de estatísticas tão furadas. Provavelmente o planejador descartou o plano ideal quando estatísticas sobre uma só coluna o induziram a erro. Quanto a isso, nenhuma solução trivial à vista. Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
