Euler, > O valor padr�o para este par�metro � med�ocre mesmo. J� houve v�rias > discuss�es sobre aumentar este valor para um valor mais condizente com a > realidade mas por falta de provas (aka testes) -- que isso n�o aumentar� > o tempo de planejamento para ter o mesmo benef�cio -- ainda n�o > decidiram se v�o aument�-lo na pr�xima vers�o.
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 ? >> 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. 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). Se o Postgres cair na besteira de fazer nested loops com o parafuso ou merge/hash join com a máquina, era uma vez servidor. Como no meu caso tenho centenas de consultas para cada gravação, não estou nem aí para quanto tempo ele leve atualizando quantos índices e estatísticas ele conseguir manter. Já criei dúzias de índices nas tabelas grandes exatamente para que uma dessas consultas arrasa-quarteirão nunca aconteça. Falando em estatísticas, já que me parece óbvio que tabelas grandes precisem de mais estatísticas, geralmente proporcionais ao número de registros, por que raios eu preciso informar valores absolutos ao invés de percentuais? Algo contra o super prático e intuitivo SAMPLING RATE do SQL Server? Mozart Hasse _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
