Mozart Hasse escreveu: > 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.
>>> Deixe seu default_statistics_target=1000 e veja se melhora. > >> 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. Dependendo da distribui��o >> dos valores da coluna e da quantidade de valores distintos valores at� >> no m�ximo 150 ou 200 s�o suficientes; normalmente, utilize entre 30 e >> 100 para tabelas maiores *e* que n�o estejam estimando o n�mero de >> tuplas retornadas pr�ximo do valor exato (um EXPLAIN ANALYZE pode te >> dizer isso). > > Discordo. > > 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)? > Não é nada incomum (aliás, chega a ser frequente) na minha aplicação eu > ter 2 ou mais planos ótimos para o mesmo SELECT, sendo que o que deve ser > escolhido depende da distribuição de dados na tabela para um determinado > valor. > > Exemplo: consultar o histórico de estoque (usando a mesmíssima query) de um > parafuso movimentado dúzias de vezes por dia exige um plano (por ex. merge ou > hash join com algum índice de outra tabela) completamente diferente de uma > máquina vendida uma vez por mês (onde provavelmente o plano ideal teria > nested loops). É 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 -- 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
