Euler, Mozart Hasse escreveu: >> 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. Ok, em qual lista as pessoas que decidem isso discutem ou discutiram esse assunto? Alguém que concorda que o valor padrão é ridículo já se manifestou por lá? >> 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; Sim, tem a ver com: * o caso mais frequente (eu acho que meu caso é), ou * com o caso que trará bom resultado para a maioria dos usuários (eu acho que meu caso traz), ou * com o caso que trouxer menos problemas para a maioria dos usuários (eu acho que meu caso traz muito pouco para justificar preocupações), ou * qualquer outro critério que tenha algo a ver com os acima (eu acho que o meu caso deveria se aplicar). > ou você acha que todas as suas colunas vão > precisar de um 'statistics_target' alto? Todas não, mas uma boa parte. Aliás, muito mais do que o suficiente para eu achar que vale a pena calcular para *todas* a fim de que ele nunca fique com pouca informação para estimar as que eu de fato preciso. > 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? Porque nem todo mundo acha satisfatório o resultado "razoável" medido em minutos, especialmente quando se coloca lado a lado com outros bancos de dados, que na mesma máquina fazem a mesma consulta sobre a mesma estrutura e os mesmos dados em poucos milissegundos. > 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. (...) > Não adianta coletar tanta informação se o tempo para analisá-las é > significativo em relação ao tempo de manipulação dos dados. Pouco importa a proporção planejamento/execução, o que interessa é atender a todas as consultas que chegam no menor tempo possível. Eu também estou falando de poupar tempo, só que fazendo as coisas da maneira mais inteligente. Usar estatísticas insuficientes é uma otimização precoce que faz com que o servidor não faça mais nada além de manipular dados de maneira ridiculamente ineficiente. > 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; Com estatísticas ruins, consultas rápidas serão fruto de *muita* sorte ou um de sistema muito, *muito* simples. Não dá para contar com a sorte em bases cheias de dados não-fictícios e tabelas interligadas. >> 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? Teoria relacional surgiu no século passado, só que de lá para cá algumas pessoas andaram pensando a respeito e melhorando o que já existia. Olha só o que o odiado concorrente fez para nunca, *nunca mesmo* ter uma mísera consulta significativamente mais lenta do que o Postgres no meu ambiente de testes: http://www.microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx > Se os valores forem bem distribuídos a estimativa é boa. Sim, só que isso é no mundo perfeito, cuja proximidade só existe em sonhos. Idealismo por idealismo, se valores fossem bem distribuídos, bancos de dados nem precisariam de estatísticas. > (i) inchaço da tabela do catálogo pg_statistic -- que pode provocar > demora na hora de obter os dados para análise Sim, isso *pode* levar mais tempo. Agora, no meu caso não ter dados estatísticos suficientes *garantidamente* deixou o servidor muito pior. > (ii) tempo de processamento dos planos pode aumentar o tempo de > execução da consulta desnecessariamente. Claro que *pode*. Só que no meu caso não ter dados estatísticos suficientes *garantidamente* deixou o servidor muito pior. > O modelo de custo do PostgreSQL foi desenhado para ser simples e > eficiente. Nada contra simplicidade, só sou contra coisas *exageradamente* simples. Que tal ser um pouco mais eficiente ao invés de ser apenas simples? > Adicionar processamento desnecessário está fora dos planos do PostgreSQL. Está fora dos meus planos também. Estou desde o começo da tópico explicando de várias maneiras que ter mais informações estatísticas *não é* desnecessário. Deu pra notar? > Novamente eu concordo que o valor é baixo (e isto é por uma > razão histórica); :-O (Acaso decidiram isso no século passado também?) :-| (Está escrito em pedra?!) :-/ > Ninguém se aventurou a mostrar com distribuições de > dados variadas que este valor não condiz com a realidade atual. Como já exposto anteriormente, aguardo divulgação de diretrizes de formato aceitas pelo julgador para "me aventurar" nessa empreitada curiosamente difícil de entender. > É fato que esta área do SGBD precisa de novas idéias mas que ninguém se aventurou a propor algo. Ninguém *do Postgres*, você quer dizer. Ok concluindo então: em qual lista as pessoas que decidem isso discutem ou discutiram esse assunto? Alguém que concorda que o valor padrão é ridículo já se manifestou por lá? Mozart Hasse _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
