Bom dia a todos ! Creio que foram colocados todas a situações possíveis nesta thread. A discussão foi bastante extensa e com certeza aprendi novas técnicas e otimização do postgree. Não quero ser dono da razão, mas o objetivo principal foi alcançado ao meu enteder e esse é a essência de um forum.
Quero a agradecer muito pela experiência que vcs vem me passando. George Um simples programador. >> 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. > O *talvez* é porque é uma técnica empírica (sem embasamento teórico). Eu e muitos concordam que o valor padrão é ridículo. >> 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. Você não entendeu a minha colocação acima. Valor padrão não tem nada a ver com um caso específico; ou você acha que todas as suas colunas vão precisar de um 'statistics_target' alto? E mais, (repetindo o que eu disse) para que gastar tanto tempo no planejamento se você consegue um resultado razoável em bem menos tempo? Lembre-se: a idéia é *estimar*. Na etapa de planejamento você não precisa de precisão (aka estatísticas altas) e sim de rapidez e um plano razoável porque a maior parte do tempo de execução deve ser gasta manipulando dados. Vale ressaltar que mesmo com estatísticas ruins, você pode ter consultas rápidas porque o planejador não sabe muita coisa a respeito de como estão armazenados os dados; isto é uma coisa que começou a ser discutida na -hackers essa semana. > 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. Não adianta coletar tanta informação se o tempo para analisá-las é significativo em relação ao tempo de manipulação dos dados. > 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. > Isso é um caso específico. > Hum, finalmente uma "fundamentação" teórica, mesmo que seja do século > passado. Século passado? De quando você acha que é a teoria relacional? > 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. Se os valores forem bem distribuídos a estimativa é boa. > 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. O problema de uma estimativa tão alta assim são (i) inchaço da tabela do catálogo pg_statistic -- que pode provocar demora na hora de obter os dados para análise (ii) tempo de processamento dos planos pode aumentar o tempo de execução da consulta desnecessariamente. O modelo de custo do PostgreSQL foi desenhado para ser simples e eficiente. Adicionar processamento desnecessário está fora dos planos do PostgreSQL. Novamente eu concordo que o valor é baixo (e isto é por uma razão histórica); ninguém se aventurou a mostrar com distribuições de dados variadas que este valor não condiz com a realidade atual. É fato que esta área do SGBD precisa de novas idéias mas que ninguém se aventurou a propor algo. -- Euler Taveira de Oliveira http://www.timbira.com/ _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
