Euler,
>> Que provas eu preciso montar ? Uma base com tabelas de 5000, 30000 e >> 700000 >> registros, alguns índices e uma dúzia de querys 60 vezes mais lentas do >> que >> uma base com esse parâmetro preenchido com valores decentes ? > Sim. Talvez uma tabela com centenas de linhas e outra com milhões de > linhas também. *Talvez* ?! Eu fiz a pergunta para saber que tipo de prova, em que formato e por qual motivo seria capaz de convencer o definidor do parâmetro default_statistics_target que o valor 10 é ridículo. Com esse "talvez" minha impressão é que nem você sabe o que poderia te convencer a mexer nesse valor. Bom, fica a proposta. Quando alguém achar que um teste prático serve para estimar um valor padrão para esse parâmetro, que especifique a fim que de passemos a discutir os critérios ou aceitemos os resultados. Ah, e claro, se alguém achar que tem embasamento *teórico* para defender um valor desses, eu adoraria saber. >>> Não faça isso! As consultas que utilizam uma coluna com o parâmetro com >>> esse valor vão demorar bem mais para serem planejadas desnecessariamente >>> sem falar em mais trabalho para o ANALYZE. (...) >> O custo de calcular as estatísticas numa tabela grande até pode parecer >> *relativamente* alto, porém calcular essa informação extra nem se compara >> com o estrago causado por um TABLE SCAN numa tabela com 1.000.000 de >> registros >> ou mais. > Eu falei acima em tempo de *planejamento* em nenhum momento mencionei > execução. É claro que uma coisa puxa a outra. Para que utilizar o valor > 500 se com 30 é a mesma coisa (custa menos para planejar)? O tempo de planejamento, por menor que seja, faz parte do tempo de execução. Já falei anteriormente que não estou nem aí que o Postgres gaste o dobro de tempo planejando *todas* as consultas se no final ele fizer um plano decente, pois o processamento que ele vai desperdiçar fazendo o plano errado nem se compara com o tempo de planejamento. O que eu expus é que coletar informação insuficiente que leve um plano de execução mal escolhido tem consequências catastróficas que justificam e muito o custo de coletar muito mais informação. Quanto ao exemplo: não, a diferença entre as estimativas com valor 500 e 30 não é pequena. O próprio paper que você citou demonstra isso na teoria e na prática, assim como todos os testes que eu já fiz ou vi nessa lista. > É exatamente para isso que serve o histograma nas estatísticas. Mas ele > armazena somente uma amostra do histograma (que pode ser grande); e > estatisticamente você não precisa de valores altos. Se quiser saber como > o PostgreSQL faz isso é só olhar o artigo do Chaudhuri [1] ou uma breve > explicação em backend/commands/analyze.c:~1526. [1] ftp://ftp.research.microsoft.com/users/autoadmin/histogram_conf.pdf Hum, finalmente uma "fundamentação" teórica, mesmo que seja do século passado. Vejamos o que diz e faz o autor do artigo: * o tamanho do histograma determina a margem de erro *mínima* que ele terá (Teorema 1 item 1). Quanto menor este histograma, obviamente maior será o erro que você terá em suas estatísticas. Aqui vemos algo claramente contrário a essa idéia de usar valores pequenos para esse parâmetro. * não há no artigo indicação de valor ideal para o tamanho do histograma. O que há são fórmulas que incluem esse valor, junto com outros parâmetros como o tamanho da tabela e a margem de erro. Disso me parece que a única justificativa para o Postgres sugerir histogramas tão pequenos é aceitar margens de erro absurdas, que em de longe me parecem adequadas para a maioria dos usuários. Aliás, fico imaginando qual é o perfil de quem pode extrair algo de útil de um histograma de tamanho 10, considerando a margem de erro mínima que ele proporciona. * em *t*o*d*o*s* os experimentos realizados pelo autor, os valores sempre foram muito acima de 10. Imagino que ele precisou usar valores maiores (50 a 600) para ter uma margem de erro suficientemente pequena para embasar alguma conclusão. Bom, pelo exposto acima continuo sem fazer idéia de qual seja a justificativa para um valor tão baixo para o parâmetro default_statistics_target. Quanto ao valor que eu sugeri (1000), minha justificativa é a baixa margem de erro que ele proporciona, que se mostrou bastante justificada para os testes que fiz no meu ambiente para meu uso. Um exemplo do grau de melhoria proporcionado por um valor tão "alto" pode ser visto na diferença entre os valores previstos e encontrados nos diversos valores de testes apresentados neste tópico. A proporção previsto/encontrado proporcionada pelo valor 1000 é o tipo de margem de erro que eu julgo necessária num histograma de otimizador. Sem mais para o momento, Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
