Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Mozart Hasse escreveu: Olhando os resultados, nota-se que neste caso o Postgres só escolheu um bom plano quando as estimativas forneceram valores completamente fora da realidade (estimado 13 encontrado 48). Isso neste caso foi ótimo, mas acho absurdo contar com isso como regra geral. Essa consulta pode até ficar mais rápida sem estatísticas, mas teoricamente é de se esperar que muitas outras consultas serão prejudicadas, enquanto que poucas vão (por puro acaso) se beneficiar de estatísticas tão furadas. Provavelmente o planejador descartou o plano ideal quando estatísticas sobre uma só coluna o induziram a erro. Quanto a isso, nenhuma solução trivial à vista. A verdade é que o PostgreSQL ficou *mais perdido que cebola em salada de fruta* (hehehe)... a única coisa que me vem na cabeça em relação a esses testes é por ser um caso muito específico, tendo em vista o volume e a distribuição dos dados... Questões de configuração de SO e do próprio PostgreSQL creio que fiz da forma adequada no ambiente em que executei, a única coisa que não modifiquei foram questoes de sistema de arquivos (tamanho de bloco, mais de um disco, separar dados e indices em sistemas de arquivos distintos, separa log de transacoes, etc.), mas também é como o colega comentou, o importante não é resultado absoluto e sim avaliacoes de resultados (ganhos e perdas)... Com certeza não tenho esse resultado como regra e somente *nesse caso específico* desabilitei as estatisticas... o restante da base de dados continua inalterada... E ainda acredito numa forma de utilizar adequadamente as estatísticas para melhorar ainda mais o desempenho das queries em relação aos resultados com elas desabilitadas (tem q ter uma forma)... quem sabe particionando a tabela??? usando indices parcias??? alguém arrisca alguma idéia??? Obrigado até o momento! Cordialmente, -- Fabrízio de Royes Mello Coordenador Desenvolvimento de Software [EMAIL PROTECTED] DBSeller Informática Ltda. - http://www.dbseller.com.br (51) 3076-5101 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Respondendo: Ninguém se interessou e *provou* que aumentando o parâmetro vai trazer benefício para todos. Bom, passei um bom tempo expondo, perguntando e esperando descobrir o que é prova suficiente para quem decide. Nessa última mensagem deu para ter uma idéia, por mais que eu discorde que precise disso para decidir algo dessa natureza. Consultas com: (i) vários tipos de dados (ii) várias distribuições desses dados (iii) número de registros variados (10, 100, 1k, 10k, 100k, 1m, 10m, 100m, 1b -- acho que é o suficiente) Nem vou entrar no mérito de quanto detalhamento precisaria para chegar em algo que a meu ver justifique alguma conclusão puramente empírica. De qualquer forma obrigado pela informação. Vou ver se providencio algo parecido quando for contatar a lista que você indicou. * o caso mais frequente (eu acho que meu caso é), ou Esses 'achos' é que precisam ser validados... Bom, quando eu souber que critério 'validou' o valor atual, posso até discutir se preciso justificar mais alguma coisa nos meus 'achos'. VACUUM ANALYZE? Qual a diferença? Nenhuma. Só faço testes depois dele. [1] http://archives.postgresql.org/pgsql-hackers/2006-09/msg01521.php [2] http://archives.postgresql.org/pgsql-patches/2007-11/msg00170.php Em [1] não vi nenhuma crítica relevante contra valores altos em estatísticas, muito pelo contrário. Pelo menos, vi sensatez no comentário sobre ter estatísticas consolidadas de várias colunas em versões futuras. Isso sem dúvida trará muito mais benefícios do que mexer em parâmetros (apesar das duas coisas irem muito melhor juntas). Em [2] não achei nada em favor do valor atual, muito pelo contrário. De qualquer forma obrigado pela referência. mesmo usando 1000 ficou mais rápido sem as estatisticas... Olhando os resultados, nota-se que neste caso o Postgres só escolheu um bom plano quando as estimativas forneceram valores completamente fora da realidade (estimado 13 encontrado 48). Isso neste caso foi ótimo, mas acho absurdo contar com isso como regra geral. Essa consulta pode até ficar mais rápida sem estatísticas, mas teoricamente é de se esperar que muitas outras consultas serão prejudicadas, enquanto que poucas vão (por puro acaso) se beneficiar de estatísticas tão furadas. Provavelmente o planejador descartou o plano ideal quando estatísticas sobre uma só coluna o induziram a erro. Quanto a isso, nenhuma solução trivial à vista. Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Caros colegas de Lista: Na semana passada um colega de lista postou uma mensagem relacionada a importncia das estatsticas para o planejador do PostgreSQL. Eu venho acompanhando com particular interesse porque j tive um problema bastante semelhante tempos atrs e depois de discutir na lista, realizar inmeros e demorados testes fui levado a concluso de que as estatstica no estavam colaborando (e olhem que na poca eu nem pensei em aumentar parmetros relativos ao coletor de estatsticas). A concluso que cheguei, por tentativa e erro, foi que para ter a melhor performance deveria desativar o seqscan e o tidscan pois o planejador estava tomando decises erradas e impossibilitando determinadas consultas. Mais de uma vez vi pessoas postando diferentes nuances do mesmo problema e tenho passado minha experincia, como depois da minha sugesto ningum postou mensagem dizendo que no funcionou deduzo que foi til e resolveu o problema. Bem, ontem o colega que deu origem a esta thread concluiu e postou o resultados dos testes que ele realizou segundo vrias colaboraes de membros. Pelo que entendi, os primeiros testes que ele realizou no puderam ser considerados vlidos por alguns detalhes que foram corrigidos e os testes refeitos com os mesmos resultados que indicam que as estatsticas no esto ajudando em nada o planejador, ou este as esta ignorando. Estes resultados batem com os que obtive a um bom tempo, mas gostaria de provar que estamos partindo de alguma premissa errada para realizar estes testes, porque se no for isso o problema estar no PostgreSQL e eu acho bem mais provvel que eu e o outro colega estejamos cometendo algum erro ou omisso. A idia que se os testes foram vlidos devemos pass-los como sugesto para correo, mas se os testes ainda no foram conclusivos no interessante encaminhar esta sugesto e incomodar ainda mais os mantenedores. Antecipadamente, e em nome de todos que j tiveram o mesmo problema, agradeo, abraos, Sergio Medeiros Santi Euler Taveira de Oliveira escreveu: Mozart Hasse escreveu: [cortando o que os outros j responderam ...] (Acaso decidiram isso no sculo passado tambm?) Ningum se interessou e *provou* que aumentando o parmetro vai trazer benefcio para todos. Como j exposto anteriormente, aguardo divulgao de diretrizes de formato aceitas pelo julgador para "me aventurar" nessa empreitada curiosamente difcil de entender. Consultas com: (i) vrios tipos de dados (ii) vrias distribuies desses dados (iii) nmero de registros variados (10, 100, 1k, 10k, 100k, 1m, 10m, 100m, 1b -- acho que o suficiente) Ok concluindo ento: em qual lista as pessoas que decidem isso discutem ou discutiram esse assunto? Algum que concorda que o valor padro ridculo j se manifestou por l? -hackers, mas j vou adiantando que se tu chegar sem os dados que citei acima eles nem vo te dar ouvidos. -- ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Caramba, ficou claro que iremos precisar na próxima PGCON discutir isso, o que acham ??? Mozart Hasse escreveu: Respondendo: Ninguém se interessou e *provou* que aumentando o parâmetro vai trazer benefício para todos. Bom, passei um bom tempo expondo, perguntando e esperando descobrir o que é prova suficiente para quem decide. Nessa última mensagem deu para ter uma idéia, por mais que eu discorde que precise disso para decidir algo dessa natureza. Para falar com quem decide, ou melhor, quem pode decidir mais rápido, vá direto às listas gringas. [1] http://archives.postgresql.org/pgsql-hackers/2006-09/msg01521.php [2] http://archives.postgresql.org/pgsql-patches/2007-11/msg00170.php Em [1] não vi nenhuma crítica relevante contra valores altos em estatísticas, muito pelo contrário. Pelo menos, vi sensatez no comentário sobre ter estatísticas consolidadas de várias colunas em versões futuras. Isso sem dúvida trará muito mais benefícios do que mexer em parâmetros (apesar das duas coisas irem muito melhor juntas). Em [2] não achei nada em favor do valor atual, muito pelo contrário. De qualquer forma obrigado pela referência. Em nenhum momento procurei defender os padrões atuais, as referências estão aí pra mostrar que muita coisa tem sido discutida, e pelo jeito a discussão ainda vai longe. Vou tentar resumir o que eu entendo da posição dos desenvolvedores do Postgres. Os valores padrões devem servir a sistemas pequenos, rodar em várias plataformas com uma performance razoável, e ainda por cima ocupar pouco espaço. É uma equação muito complexa, e por essa razão, os valores padrões de memória (shared, work, maintenance...) são tão ridículamente pequenos. Para qualquer sistema da vida real, você vai precisar especificar configurações de memória, bem como configurar as suas tabelas para terem estatísticas mais precisas em certas colunas, como o outro colega fez aumentando de 10 para 1000. Ele está certo em testar e fazer alterações. Basicamente, o padrão não serve pra quase ninguém, mas roda em qualquer lugar; creio que seja essa a idéia do Postgres. Tanto que qualquer mudança nos padrões, por menor que seja, demora pra ser aceita e implementada. mesmo usando 1000 ficou mais rápido sem as estatisticas... Olhando os resultados, nota-se que neste caso o Postgres só escolheu um bom plano quando as estimativas forneceram valores completamente fora da realidade (estimado 13 encontrado 48). Isso neste caso foi ótimo, mas acho absurdo contar com isso como regra geral. Essa consulta pode até ficar mais rápida sem estatísticas, mas teoricamente é de se esperar que muitas outras consultas serão prejudicadas, enquanto que poucas vão (por puro acaso) se beneficiar de estatísticas tão furadas. Provavelmente o planejador descartou o plano ideal quando estatísticas sobre uma só coluna o induziram a erro. Quanto a isso, nenhuma solução trivial à vista. Fazer errado pra dar certo não dá. Concordo plenamente. -- []´s, ACV -- ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
George escreveu: Caramba, ficou claro que iremos precisar na próxima PGCON discutir isso, o que acham ??? Hacker Talks? Seria uma boa. -- []s Dickson S. Guedes Administrador de Banco de Dados Projeto Colmeia - Florianópolis, SC (48) 3322-1185, ramal: 26 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Em 28/10/08, George[EMAIL PROTECTED] escreveu: ... A discussão foi bastante extensa e com certeza aprendi novas técnicas e otimização do postgree. Tudo bem, mas o nome é PostgreSQL ou simplesmente postgres. Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Tudo bem, mas o nome é PostgreSQL ou simplesmente postgres. Osvaldo Se eu não me engano isso foi falado na ultima PGCON. Como eu sou burrinho ! Mas vc podia dar um desconto né ! Obrigado pela informação.. ! George Um simples burrinho Programador ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/28, George [EMAIL PROTECTED]: Tudo bem, mas o nome é PostgreSQL ou simplesmente postgres. Osvaldo Se eu não me engano isso foi falado na ultima PGCON. Como eu sou burrinho ! Mas vc podia dar um desconto né ! Obrigado pela informação.. ! A maioria dos participantes da lista, creio eu, gosta muito do PostgreSQL e, por isso, quer sempre vê-lo citado corretamente. Discordo do burrinho pois, se assim o fosse, certamente não estaria usando o PostgreSQL. Desatento, talvez... rs Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
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
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/28 Mozart Hasse [EMAIL PROTECTED]: Ok, em qual lista as pessoas que decidem isso discutem ou discutiram esse assunto? -hackers Alguém que concorda que o valor padrão é ridículo já se manifestou por lá? Por que você acha que o Euler pediu os dados? ;-) * o caso mais frequente (eu acho que meu caso é), ou Esses 'achos' é que precisam ser validados... 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 VACUUM ANALYZE? Qual a diferença? 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? Primeiro, porque essas coisas ainda estão evoluindo. Há pouco tempo atrás, os atuais valores default eram razoáveis. Segundo, porque a complexidade não é vantagem. É melhor manter o simples enquanto se pensa no ideal que sair gastando recursos para fazer algo que depois se provará sub-ótimo. 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. Hm, o Euler já deu umas boas dicas, o que te falta exatamente? Não ficou claro. Na verdade, tua irritação, justificada ou não, ficou clara, mas não exatamente o que você quer. É 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. O que ele quer dizer, e o que ele disse. O artigo especifica. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Mozart Hasse escreveu: 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á? Tente acompanhar esta thread [1], é um pouco antiga mas pode ajudar a esclarecer alguns pontos. Creio que o valor padrão, de 10 valores diferentes, é utilizado porque (i) poucas colunas tem índices e (ii) tamanho reduzido de pg_statistic. Veja em [2] que já tentaram alterar este valor, inclusive tentando alterar de acordo com o tipo do dado. [1] http://archives.postgresql.org/pgsql-hackers/2006-09/msg01521.php [2] http://archives.postgresql.org/pgsql-patches/2007-11/msg00170.php -- []´s, ACV ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Mozart Hasse escreveu: 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Bom, algumas observações: A questão é que tentei valores das estatisticas justamente pro PostgreSQL não despender tempo desnecessário com o planejamento (verifiquei colunas estimadas e retornadas como recomendastes)... o caso é que o valor que melhor se ajustou foi 1000, Idem, para todos os casos em que algum dia me dei ao trabalho de otimizar qualquer consulta em Postgres. Tempo de Execução: 84195.499 ms *MENOR TEMPO DE TODOS* O tempo até que é útil, mas considerando a disparidade de resultados, é bom mandar logo o EXPLAIN completo da query para ver o que ele fez em cada caso. Se o plano foi o mesmo (entre as estatísticas é possível), a diferença se deve ao cache. Agora, a diferença entre os tempos com e sem estatísticas só pode ser explicada por um plano diferente. Sabendo o plano, dá para imaginar o que o Postgres usou ou deixou de usar para chegar ao plano ideal. Bom, agora falando sobre o que eu considero mais importante: é muito difícil você conseguir obter bons resultados rodando em um notebook, com apenas 800Mhz por core. O problema não é resultado absoluto, e sim diferença entre resultados no mesmo ambiente. Se o importante é a comparação entre resultados, qualquer processador serve. Se acha que esse processador é lento, seria bom mostrar que parâmetro faria ele usar outro recurso de forma a executar a consulta num tempo decente. Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Euler, Que provas eu preciso montar ? Uma base com tabelas de 5000, 3 e 70 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Pessoas que, como eu, tem muito apreo pelo Postgresql e seus mantenedores: No estava me referindo a ningum em especial, mas algo que procuro me lembrar e que recomendo a todos. interessante lembrar como a histria toda comeou: a. Algum reportou um estranho problema de performance; b. passou uma srie de detalhes e testes (neste ponto me tocou porque tambm passei por isso e tambm no consegui explicaes plausveis); c. membros fizeram sugestes que foram seguidas e os resultados postados; d. aps uma trabalheira de algum o assunto comeou a esmaecer (neste momento resolvi apimentar a relao para evitar que como outras vezes essa excelente lista deixasse a peteca cair). e. algum sugeriu um processo automtico ou semi na instalao (o que acho bem razovel por se tratar basicamente de grandezas constantes como memria); f algum sugeriu que isto poderia ser dinmico (o que me parece mais complexo, mas ainda assim, plausvel); g. mais ou menos neste momento comearam alguns comentrios que levavam a crer que isto era algo to complexo, to difcil, tantas vezes tentado sem sucesso, ..., que no valia a pena gastar tempo com isto (neste ponto lembrei: 1. daquele cara "que sem saber que era impossvel, foi l e fez", 2. daquela do pipoqueiro que formou o filho em administrao e este grato ao pai resolveu "desenvolver" o negcio e depois de contratar um o staff, consultorias, agentes de marketing acabou falindo e 3. tambm que se um assunto no aparece ou pouco debatido ele dificilmente ser considerado pelas pessoas que pensam as caractersticas desejveis em uma nova verso). Assim sendo e como acredito que se fosse to complexo outros bancos no teriam ferramentas nesta linha estou dando minha contribuio a que este assunto no morra, que conste nas estatsticas da lista e que isto sirva como indicador de features a incluir em futuras verses. Tambm pretende ser uma palavra de estmulo a todos os que tentam, testam, demonstram e discutem sem medo de serem taxados de inexperientes. Talvez dessa massa crtica surjam braos para contribuir com o desenvolvimento do nosso to querido e porreta Postgresql. Durante essa discusso algum teve a curiosidade cientfica de desabilitar suas estatsticas e ver como o planejador reage? Alterou parmetros e observou como ficou o plano de execuo. Eu, h um bom tempo atrs, fiz testes deste tipo e como o colega que iniciou esta thread no consegui concluir muita coisa mas apesar de ter discutido o assunto nesta lista no tive resposta melhores que esta vez, mas como ele tenho seqscan e tidscan desabilitados porque nos testes que fiz com esses cara habilitados os resultados eram desastrosos. Tambm j vi muita gente reclamando nesta lista de performance pobre aos quais respondo com base nas experincias que tive e as reclamaes cessam (quero crer que o problema parou ou ao menos melhorou significativamente). Bem, amigos, eu gostaria de ter tempo disponvel para poder grandes testes de performance e gerar um tutorial de tunning, depois uma ferramenta, depois (quem sabe) incorpor-la ao Postgresql, mas no momento preciso aceitar minhas capacidades e tentar contribuir com o que me for possvel. Como j fim de semana espero que o tamanho desta mensagem no incomode muito. Um grande abrao a todos e longa vida ao Postgresql! Euler Taveira de Oliveira escreveu: Sergio Medeiros Santi escreveu: Talvez o que esteja ocorrendo algo que acontece frequentemente conhecido como "soberba", onde as pessoas formadoras de opinio e que podem influir positivamente no o fazem, simplesmente porque no tem "tempo" de ouvir suas comunidades. [No sei se voc est dirigindo esta ltima frase a minha pessoa mas...] (i) em nenhum momento eu deixei de fornecer informaes ao colega; (ii) eu "ouo" esta comunidade tanto verdade que vrias correes de erros e melhorias surgiram de idias discutidas aqui; (iii) eu _no_ sou financiado por nenhuma empresa que trabalha com PostgreSQL e, se fosse, talvez poderia me dedicar mais a funcionalidades interessantes do ponto de vista do usurio; (iv) se o tal auto-tuning fosse fcil de fazer com certeza ele j estaria disponvel; (v) no h frmula mgica para tuning (vejo que pela recorrncia do tema na lista talvez alguns dos gurus palestrantes pensassem em palestras sobre o tema nas prximas conferncias -- Ike-san?). Voltando a discusso inicial ... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/24 Sergio Medeiros Santi [EMAIL PROTECTED]: Esqueci de mencionar, na mensagem anterior, que não quero desviar o foco. Tem um companheiro de lista que deve ter consumido um tempo significativo testando e tentando medir a eficiência de diferentes abordagens que ainda não teve uma resposta. Como não? Tenho aqui mais de uma dúzia de mensagens, muitas das quais são de um bate-e-volta sobre os testes que ainda não terminou. Acho que a atitude dele não pode ser considerada falta de braços. Talvez o que esteja ocorrendo é algo que acontece frequentemente conhecido como soberba, onde as pessoas formadoras de opinião e que podem influir positivamente não o fazem, simplesmente porque não tem tempo de ouvir suas comunidades. Não é bom julgar sem conhecimento de causa. O que é prioridade para uns não é para outros, e nenhuma organização tem recursos para atender todos os usuários. Falta de braços é comum; o que não pode são braços curtos. Aliás: desde quando alguém é obrigado a ouvir a comunidade? Lembre-se de que são todos voluntários, e a menos que você tenha um contrato de suporte, não é bom esperar que alguém tenha a obrigação de te atender. Devemos, sim, sermos gratos por tudo o que temos. Não deixe tua irritação com a vida transbordar e afetar quem não tem nada a ver com teus problemas, só está te fazendo um favor. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
O que eu temia est acontecendo. Meu comentrio acabou desviando o foco quando o objetivo era o contrrio. E claro que ningum obrigado a ouvir uma comunidade. Inclusive muita comunidade boa sucumbiu motivada por essa "surdez". A falta de uso e de massa crtica j destruiu uma srie de idias maravilhosas, no vamos deixar isto acontecer com o PG, por favor. Nem deixar que nosso ego se sobreponho aos interesses de toda uma comunidade. Eu acreditei que havia dado inmeras indicaes de apreo e respeito ao PG e a comunidade que o mantm e tambm por querer que continue assim que no fico apenas "rasgando seda", mas sugerindo coisas que alguns julgam importantes para que se os desenvolvedores conclurem que interessante e til. Finalmente, eu no notei estar irritado, inclusive estou de muito bom humor, mas posso sem querer ter espelhado alguma coisa ou feito aflorar algum desafeto. No goste de ser repetitivo, mas quero manifestar novamente minha satisfao em fazer parte da comunidade de usurios do PG e de desejar que esta comunidade e o PG cresam em poder e em sabedoria. De minha parte no pretendo contribuir para afastar ainda mais o foco e se no houver motivao encerro aqui minha contribuio a esta thread sob pena de daqui a pouco estaremos discutindo quem matou Elo ou o sexo dos anjos. Abraos e bom fim de semana a todos P.S. Meus fins de semana esto muito mais tranquilos depois que adotei o Postgresql. Sergio Medeiros Santi Leandro DUTRA escreveu: 2008/10/24 Sergio Medeiros Santi [EMAIL PROTECTED]: Esqueci de mencionar, na mensagem anterior, que no quero desviar o foco. Tem um companheiro de lista que deve ter consumido um tempo significativo testando e tentando medir a eficincia de diferentes abordagens que ainda no teve uma resposta. Como no? Tenho aqui mais de uma dzia de mensagens, muitas das quais so de um bate-e-volta sobre os testes que ainda no terminou. Acho que a atitude dele no pode ser considerada falta de braos. Talvez o que esteja ocorrendo algo que acontece frequentemente conhecido como "soberba", onde as pessoas formadoras de opinio e que podem influir positivamente no o fazem, simplesmente porque no tem "tempo" de ouvir suas comunidades. No bom julgar sem conhecimento de causa. O que prioridade para uns no para outros, e nenhuma organizao tem recursos para atender todos os usurios. Falta de braos comum; o que no pode so braos curtos. Alis: desde quando algum obrigado a ouvir a comunidade? Lembre-se de que so todos voluntrios, e a menos que voc tenha um contrato de suporte, no bom esperar que algum tenha a obrigao de te atender. Devemos, sim, sermos gratos por tudo o que temos. No deixe tua irritao com a vida transbordar e afetar quem no tem nada a ver com teus problemas, s est te fazendo um favor. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/24 Sergio Medeiros Santi [EMAIL PROTECTED]: ...muita comunidade boa sucumbiu motivada por essa surdez. A falta de uso e de massa crítica já destruiu uma série de idéias maravilhosas, não vamos deixar isto acontecer com o PG, por favor. Pode ficar tranqüilo, a comunidade é muito maior que esta lista... -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
De vez em quando bom fazer mexer os agu-pes. Acabei achando o material de um tocaio bem interessante. Parece que algo est mesmo por acontecer. Dem uma olhada em http://www.inf.ufsc.br/erbd2008/palestras/sergio/Sergio.ppt e em http://www.inf.puc-rio.br/~postgresql/ Enfim uma luz no fim do tnel que no trem. Sergio Medeiros Santi Leandro DUTRA escreveu: 2008/10/24 Sergio Medeiros Santi [EMAIL PROTECTED]: ...muita comunidade boa sucumbiu motivada por essa "surdez". A falta de uso e de massa crtica j destruiu uma srie de idias maravilhosas, no vamos deixar isto acontecer com o PG, por favor. Pode ficar tranqilo, a comunidade muito maior que esta lista... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/24 Sergio Medeiros Santi [EMAIL PROTECTED]: De vez em quando é bom fazer mexer os aguá-pes. Acabei achando o material de um tocaio bem interessante. Parece que algo está mesmo por acontecer. Tocaio? Qu'est-ce que c'est ça ? Dêem uma olhada em http://www.inf.ufsc.br/erbd2008/palestras/sergio/Sergio.ppt e em Foi o gajo que apresentou isso ano passado no I PgConBR (2007-12)? Se sim, será que ele já conseguiu se apresentar ao PGDG? Ele teve no passado alguns problemas de comunicação intercultural... -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Fabrizio Mello - Pessoal escreveu: Pessoal, O amigo Mozart expressou bem o *sentimento de indignação* quanto a esse mistério que são as configurações para *tunning* do nosso elefantinho. Tuning é uma arte muitas vezes incompreendida. Ter paciência e bom senso é essencial, vou tentar ajudar aqui me baseando nos testes e experiências que tive. Dando continuidade a esse *dilema* vamos a resultados práticos que obtive e, como iremos ver, continuam estranhos... Tenho as seguintes tabelas envolvidas no teste: - NotaFiscal ( 2.162.878 registros) - NotaItem (28.041.370 registros) - Produto(41.911 registros) Tua base é de pequena pra média, acho que dá pra melhorar bastante esses tempos. corta 6) Estatisticas = 0 (desabilitado) nas Colunas das Tabelas NotaFiscal e NotaItem, mas com uma pequena modificação no SELECT: DataMovimentoNota between '2008-04-01' and '2008-04-30' (Selecionado o Mes Inteiro) Linhas Estimadas: 13 Linhas Retornadas: 1.266.367 Tempo de Execução: 84195.499 ms *MENOR TEMPO DE TODOS* Obs: Agora uma surpresa... ~84seg para retornar 1.266.367, muito menos que os ~13min q levou com as estatisticas setadas pra 1000 Acho que você deveria esquecer um pouco o parâmetro de estatísticas da tabela, e voltar a ele assim que a casa estiver arrumada. Sobre o que o Euler disse do cache do SO, ele está armazenando o resultado das querys e está influenciando nesse resultado. Para zerar o cache, não basta reiniciar o PG, pare o serviço e digite: # echo 3 /proc/sys/vm/drop_caches Inicie o banco novamente, mude apenas um parâmetro de cada vez, e repita o analyze. Bom, agora falando sobre o que eu considero mais importante: é muito difícil você conseguir obter bons resultados rodando em um notebook, com apenas 800Mhz por core. Não sei qual é o teu ambiente de produção, mas o ideal seria se você conseguisse testar em um ambiente parecido. A velocidade do clock e o tamanho do cache (quase inexistente neste notebook) influencia bastante em joins e sorts. Mande pra gente como é o teu ambiente de produção, inclusive se existem partições e RAIDs. Neste ambiente de testes, com um HD fazendo tudo, fica meio difícil ter ganhos maiores. Sobre o postgresql.conf, habilite todos os planos do planejador. Seq scans são muito úteis para filtros e buscas em tabelas pequenas. Não tente enganar o planejador, tente fazer ele acertar o máximo nas estatísticas; não faz sentido que uma query rode mais rápido se o planejador estiver errado. É apenas uma questão de bom senso, *muita* gente boa trabalhou em cima de otimizações para o planejador. Ele é mais esperto do que você ;) Veja também se a versão do PG é a mesma nos ambientes de teste e produção. Se for, atualize para a última do 8.2. PS: Sobre os auto-tunnings, apesar do enorme esforço da comunidade, creio que ainda estamos engatinhando. Nenhuma das propostas foi pra frente, que eu saiba ... -- []´s, ACV ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/24 André Volpato [EMAIL PROTECTED]: Bom, agora falando sobre o que eu considero mais importante: é muito difícil você conseguir obter bons resultados rodando em um notebook, com apenas 800Mhz por core. Até que ponto a velocidade do processador influi? Na minha experiência, a quantidade e velocidade de memória disponível, inclusive os vários níveis de cache e tanto memória volátil quanto de massa (discos), é muito, mas muito mesmo, mais importante. PS: Sobre os auto-tunnings, apesar do enorme esforço da comunidade, creio que ainda estamos engatinhando. Nenhuma das propostas foi pra frente, que eu saiba ... Que me lembro, aquele professor que se apresentou ano passado já tinha coisas interessantes, ele só não conseguiu se comunicar com os desenvolvedores por falta de traquejo intercultural... -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Leandro DUTRA escreveu: 2008/10/24 Andr Volpato [EMAIL PROTECTED]: Bom, agora falando sobre o que eu considero mais importante: muito difcil voc conseguir obter bons resultados rodando em um notebook, com apenas 800Mhz por core. At que ponto a velocidade do processador influi? Na minha experincia, a quantidade e velocidade de memria disponvel, inclusive os vrios nveis de cache e tanto memria voltil quanto de massa (discos), muito, mas muito mesmo, mais importante. Em sistemas pequenos, onde as querys cabem na memria, pode ocorrer muito gargalo de processador, aka 100% de CPU por muito tempo. Nosso amigo poderia enviar um "dstat" ou similar do servidor pra gente ter certeza. Logicamente, quanto mais discos (rpidos) melhor, mas acho que o ganho s seria sentido com concorrncia, o que no o caso. PS: Sobre os auto-tunnings, apesar do enorme esforo da comunidade, creio que ainda estamos engatinhando. Nenhuma das propostas foi pra frente, que eu saiba ... Que me lembro, aquele professor que se apresentou ano passado j tinha coisas interessantes, ele s no conseguiu se comunicar com os desenvolvedores por falta de traquejo intercultural... Sim, eu vi a palestra e tambm achei interessante. Mas vejo o esforo desse professor se tornar no mximo um contrib, nada que entre no core. Pensando alto, lembrando do comentrio do Alexandre na palestra de replicao... A entramos na velha questo tostines aplicada a manuteno do PostgreSQL: Faltam parmetros de ajuste fino porque poucos se importam, ou existem poucos que se importam porque faltam parmetros de ajuste fino ? Bah, era quase isso... -- []s, ACV ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/24 André Volpato [EMAIL PROTECTED]: Sim, eu vi a palestra e também achei interessante. Mas vejo o esforço desse professor se tornar no máximo um contrib, nada que entre no core. Por quê? Se ele ou algum colaborador conseguirem se colocar no PGDG... Eu mesmo gostaria de fazer essa intermediação, se tivesse condições. Hoje, não tenho. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Leandro DUTRA escreveu: 2008/10/24 Andr Volpato [EMAIL PROTECTED]: Sim, eu vi a palestra e tambm achei interessante. Mas vejo o esforo desse professor se tornar no mximo um contrib, nada que entre no core. Por qu? Se ele ou algum colaborador conseguirem se colocar no PGDG... Eu mesmo gostaria de fazer essa intermediao, se tivesse condies. Hoje, no tenho. Na verdade eu no vi o pessoal se animar muito com idias de auto configurao, ento o problema maior convencer os mais conservadores do PGDG. Eu particularmente acho interessante um auto-tunning baseado no hardware, quantidade de memria, discos, cpu. E tambm no tipo de aplicao. No quero me estender muito aqui, j que esta thread j foi desviada vrias vezes.. :) -- []s, ACV ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/24 André Volpato [EMAIL PROTECTED]: Na verdade eu não vi o pessoal se animar muito com idéias de auto configuração, então o problema maior é convencer os mais conservadores do PGDG. Aí é que você — e a torcida do Corinthians — se engana. A questão não é falta de interesse, nem conservadorismo; embora conservadorismo seja altamente desejável em mantenedores de SGBDs. É simples falta de comunicação. O cara está preocupado com bits e bytes, e você chega com um negócio de outro mundo. Tem de se explicar, e isso tem de ser feito com certa habilidade. Eu e Euler apresentamos um /Hacker Talk/ sobre isso no II PgConBR (2008-09). -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Leandro DUTRA escreveu: 2008/10/24 André Volpato [EMAIL PROTECTED]: Na verdade eu não vi o pessoal se animar muito com idéias de auto configuração, então o problema maior é convencer os mais conservadores do PGDG. Aí é que você — e a torcida do Corinthians — se engana. Me incluo nessa... :-P A questão não é falta de interesse, nem conservadorismo; embora conservadorismo seja altamente desejável em mantenedores de SGBDs. Sim, concordo. Entre radicais e conservadores o time do PGDG sempre achou um equilíbrio. Como a essência do Postgres é conservadora, questões como compatibilidade e portabilidade tem um peso enorme. Ah, ainda bem! :-) É simples falta de comunicação. O cara está preocupado com bits e bytes, e você chega com um negócio de outro mundo. Tem de se explicar, e isso tem de ser feito com certa habilidade. Eu e Euler apresentamos um /Hacker Talk/ sobre isso no II PgConBR (2008-09). Muitas vezes vejo gente tentando convencer o PGDG, nem sempre com sucesso. Foi o caso daquela thread que o Guedes mandou, mesmo com argumentos bem fundamentados e boa comunicação não se consegue convencer a todos. -- []´s, ACV ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/24 André Volpato [EMAIL PROTECTED]: Muitas vezes vejo gente tentando convencer o PGDG, nem sempre com sucesso. Foi o caso daquela thread que o Guedes mandou, mesmo com argumentos bem fundamentados e boa comunicação não se consegue convencer a todos. Uai, não enxerguei isso. Será que lemos as mesmas mensagens? O que estou lendo é uma discussão super-produtiva onde não se aceitam as aparências, mas vai-se fundo no problema... -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Leandro DUTRA escreveu: 2008/10/24 Andr Volpato [EMAIL PROTECTED]: Muitas vezes vejo gente tentando convencer o PGDG, nem sempre com sucesso. Foi o caso daquela thread que o Guedes mandou, mesmo com argumentos bem fundamentados e boa comunicao no se consegue convencer a todos. Uai, no enxerguei isso. Ser que lemos as mesmas mensagens? O que estou lendo uma discusso super-produtiva onde no se aceitam as aparncias, mas vai-se fundo no problema... Super produtiva, sim, concordo. Tomara que alguma coisa dessas mudanas entre no core, mas pelo jeito ainda demora um pouco. -- []s, ACV ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/24 André Volpato [EMAIL PROTECTED]: Tomara que alguma coisa dessas mudanças entre no core, mas pelo jeito ainda demora um pouco. Essa é a beleza. Sem pressa, com qualidade. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Leandro DUTRA escreveu: 2008/10/24 Sergio Medeiros Santi [EMAIL PROTECTED]: De vez em quando é bom fazer mexer os aguá-pes. Acabei achando o material de um tocaio bem interessante. Parece que algo está mesmo por acontecer. Tocaio? Qu'est-ce que c'est ça ? Dêem uma olhada em http://www.inf.ufsc.br/erbd2008/palestras/sergio/Sergio.ppt e em Foi o gajo que apresentou isso ano passado no I PgConBR (2007-12)? Se sim, será que ele já conseguiu se apresentar ao PGDG? Ele teve no passado alguns problemas de comunicação intercultural... A idéia dele não foi para frente mas outra pessoa implementou a mesma coisa de uma maneira menos invasiva (utilizando hooks). É um projeto [1] a parte mas que precisa ser lapidado. (Infelizmente eu não tenho tempo para tal façanha). [1] http://pgfoundry.org/projects/pgadviser/ -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Sergio Medeiros Santi escreveu: Talvez o que esteja ocorrendo é algo que acontece frequentemente conhecido como soberba, onde as pessoas formadoras de opinião e que podem influir positivamente não o fazem, simplesmente porque não tem tempo de ouvir suas comunidades. [Não sei se você está dirigindo esta última frase a minha pessoa mas...] (i) em nenhum momento eu deixei de fornecer informações ao colega; (ii) eu ouço esta comunidade tanto é verdade que várias correções de erros e melhorias surgiram de idéias discutidas aqui; (iii) eu _não_ sou financiado por nenhuma empresa que trabalha com PostgreSQL e, se fosse, talvez poderia me dedicar mais a funcionalidades interessantes do ponto de vista do usuário; (iv) se o tal auto-tuning fosse fácil de fazer com certeza ele já estaria disponível; (v) não há fórmula mágica para tuning (vejo que pela recorrência do tema na lista talvez alguns dos gurus palestrantes pensassem em palestras sobre o tema nas próximas conferências -- Ike-san?). Voltando a discussão inicial ... -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Fabrízio de Royes Mello escreveu: Euler Taveira de Oliveira escreveu: Sim. Sem isso você está encorajando o PostgreSQL a excluir alguns possíveis caminhos que o planejador pode percorrer por questões de pouca memória. E quais são esses *possíveis caminhos*??? Quais parâmetros interferem??? Os caminhos são diversos. Os parâmetros que interferem estão nas seções 'Resource Usage' (Memory) e 'Query Tuning'. Não, estou me referindo a cache do *SO*; a do PostgreSQL se perde em um reínicio do serviço. Apesar de eu não acreditar que isso vá fazer diferença vou fazer o que recomendas e refazer os testes... Faz sim. Que escolhas dependem de que parâmetros??? Isso é muito subjetivo... terias como exemplificar isso? Tipo se alterar parametro tal aumenta ou diminui o tempo de planejamento, ou utiliza uma estratégia diferente de planejamento, etc... Isso é tema para um livro. ;) Para que você consiga otimizar consultas SQL, você deve conhecer os algoritmos de junção (hash join, merge join, nested loop), algoritmos de agregação, funcionamento de índices (inclusive os funcionais e parciais) e *principalmente* o modelo de custo utilizado pelo PostgreSQL (src/backend/optimizer/path/costsize.c pode ser um bom começo). Se houvesse uma receita de bolo com certeza alguém já tinha escrito. Há livros que tratam desse assunto mas nenhum específico ao PostgreSQL. Tem um livro que trata do assunto de maneira genérica e que eu particularmente recomendo (SQL Tuning, Dan Tow). Ele aborda alguns dos pontos que falei acima. Apesar de já ser tarde, eu vou exemplificar a dinâmica do modelo de custo do PostgreSQL. Ao alterar o parâmetro random_page_cost, o algoritmo de junção interna foi alterado. Por quê? Justamente porque ao favorecer a busca sequencial (diminuindo o random_page_cost) fizemos com o que o custo do 'merge join' fique mais vantajoso do que um 'hash join'. regression=# set random_page_cost to 2.5; SET regression=# explain analyze select count(*) from tenk1 a inner join tenk1 b on (a.unique1=b.thousand) where b.unique2 1000 limit 300; QUERY PLAN Limit (cost=1330.41..1330.42 rows=1 width=0) (actual time=163.743..163.748 rows=1 loops=1) - Aggregate (cost=1330.41..1330.42 rows=1 width=0) (actual time=163.736..163.737 rows=1 loops=1) - Hash Join (cost=605.00..1307.78 rows=9052 width=0) (actual time=66.528..148.729 rows=8999 loops=1) Hash Cond: (b.thousand = a.unique1) - Seq Scan on tenk1 b (cost=0.00..470.00 rows=9052 width=4) (actual time=1.331..21.611 rows=8999 loops=1) Filter: (unique2 1000) - Hash (cost=445.00..445.00 rows=1 width=4) (actual time=65.043..65.043 rows=1 loops=1) - Seq Scan on tenk1 a (cost=0.00..445.00 rows=1 width=4) (actual time=0.013..35.482 rows=1 loops=1) Total runtime: 163.979 ms (9 registros) regression=# set random_page_cost to 2.2; SET regression=# explain analyze select count(*) from tenk1 a inner join tenk1 b on (a.unique1=b.thousand) where b.unique2 1000 limit 300; QUERY PLAN -- Limit (cost=1234.92..1234.93 rows=1 width=0) (actual time=143.700..143.705 rows=1 loops=1) - Aggregate (cost=1234.92..1234.93 rows=1 width=0) (actual time=143.692..143.693 rows=1 loops=1) - Merge Join (cost=1.02..1212.29 rows=9052 width=0) (actual time=0.175..128.241 rows=8999 loops=1) Merge Cond: (a.unique1 = b.thousand) - Index Scan using tenk1_unique1 on tenk1 a (cost=0.00..961.94 rows=1 width=4) (actual time=0.091..3.583 rows=1001 loops=1) - Index Scan using tenk1_thous_tenthous on tenk1 b (cost=0.00..1000.24 rows=9052 width=4) (actual time=0.059..76.166 rows=8999 loops=1) Filter: (b.unique2 1000) Total runtime: 143.972 ms (8 registros) -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
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, 3 e 70 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
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/23 Mozart Hasse [EMAIL PROTECTED]: O valor padr�o para este par�metro � med�ocre mesmo. J� houve Herr Haße, tua mensagem veio em BASE64 com codificação errada... 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, 3 e 70 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 ? Pode começar por aí, desde que esteja bem documentado... A questão é, a partir de provas tais, achar um equilíbrio entre as necessidades de pequenos sistemas embutidos e grandes sistemas corporativos. 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. A questão é se vale jogar o valor geral para o alto, ou dar um aumento moderado geral e só jogar para bem mais alto determinadas tabelas. E se é necessário 1000 como você propõe, ou no máximo 300 como o Euler propôs. Conversando a gente se entende... -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Grande Dutra, Que provas eu preciso montar ? Uma base com tabelas de 5000, 3 e 70 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 ? Pode começar por aí, desde que esteja bem documentado... Bom, basta à cúpula do Postgres definir um padrão para esse tipo de informação então. Enquanto ficar no julgamento subjetivo valor nenhum vai mudar. A questão é, a partir de provas tais, achar um equilíbrio entre as necessidades de pequenos sistemas embutidos e grandes sistemas corporativos. Bom, se temos diversos tipos de uso para o Postgres, cada qual com suas peculiaridades, por que não criar logo um arquivo de configuração para cada perfil? Imaginando um mundo melhor: o sujeito responderia 3 ou 4 perguntas sobre seu hardware, 1 ou 2 sobre o uso mais frequente do servidor e o instalador já coloca no lugar um arquivo .config bem próximo do que ele precisa. Duas ou 3 perguntas na hora de criar o banco de dados (resultando num monte de SETs que usam essas perguntas e a configuração do servidor para chegar num conjunto de opções decente) também facilitariam muito as coisas para o DBA. Claro, isso ainda fica meio longe do mundo perfeito do servidor auto-configurável, mas tentar ir nessa direção (ao menos para ir para o mesmo lado dos que estão quase lá) não seria nada mal... 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. A questão é se vale jogar o valor geral para o alto, ou dar um aumento moderado geral e só jogar para bem mais alto determinadas tabelas. E se é necessário 1000 como você propõe, ou no máximo 300 como o Euler propôs. 1000 numa tabela pequena gera um pouco de desperdício, mas não é muito, já que a tabela é pequena e o processamento sobre ela não é grande coisa. Agora, 300 numa tabela grande tem boa chance de ser um desastre. Bom, estamos de novo em julgamentos subjetivos, tentemos colocar alguma objetividade: Já que as discussões anteriores sobre aumentar esse valor acabaram por falta de provas de que um novo valor seria mais interessante, mesmo que contrário aos que já testaram com valores maiores e encontraram melhores resultados, que tal propor a essas mentes tão convictas que montem um ambiente em que esses valores proporcionem um desempenho tão maravilhoso quando comparado ao resultado de nossos experimentos? O ônus da prova cabe a quem afirma. Quem afirmou que 10 é um bom valor a ponto de não mudá-lo nem atendendo a pedidos, que prove. Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Mozart Hasse escreveu: Que provas eu preciso montar ? Uma base com tabelas de 5000, 3 e 70 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Bom, quero contar minha história ...quem sabe posso ajudar ou atrapalhar Tive uma tabela na base de dados que faz a seguinte conta Numero de clientes.. : 1089 Numero médio de equipamentos por cliente : 4 Numero de eventos que gera cada equipamento por hora: 8 (eventos gerados via IP) Numero de dias acumulado no banco : 1 ano Tabela Eventos = 1089 *4 * (8*24*365) = 305.268. 480 Que loucura ! Comecei a ter muitos problemas em relação a consultas destes eventos, porque todos os clientes internos e externos a acessavam e ainda bem que não tinha update ou delete desta tabela ! U ! Claro tentei várias soluções e nada ! Continuava lento que dói. Tive a idéia infeliz de . 1. Criar um esquema de eventos 2. Mover a tabela eventos para este schema (cli, eqp, dta, eve, dta, hms). 3. Criar tabelas (cli_XX) de herança da tabela de eventos no schema eventos 4. Criar tabelas (eqp_XX) de herança das tabelas cli_XX no schema 5. Criar dinamicamente as tabelas de herança no cadastro de clientes e equipamentos através de trigger; 6. Alterar todas as funções e trigger para realizar tratamento dinamicamente. 7. Alterar a regra de negócio para o banco de dados em relaçãoa eventos. 8. Outras coisitas mais Resultado ! Consegui atender a necessidade do cliente em questão a performance e não tive mais problemas. Hoje em outro cliente estou desenvolvendo esta mesma regra para um sistema de Gestão de Estoque e Financeiro (Saldos, extratos...). PS. Esqueci de dizer que ainda tem 678 clientes que enviam dados via telefone (média de 24 eventos dia). Entendam não sou DBA, mas sim um simples programador. Grande Dutra, Que provas eu preciso montar ? Uma base com tabelas de 5000, 3 e 70 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 ? Pode começar por aí, desde que esteja bem documentado... Bom, basta à cúpula do Postgres definir um padrão para esse tipo de informação então. Enquanto ficar no julgamento subjetivo valor nenhum vai mudar. A questão é, a partir de provas tais, achar um equilíbrio entre as necessidades de pequenos sistemas embutidos e grandes sistemas corporativos. Bom, se temos diversos tipos de uso para o Postgres, cada qual com suas peculiaridades, por que não criar logo um arquivo de configuração para cada perfil? Imaginando um mundo melhor: o sujeito responderia 3 ou 4 perguntas sobre seu hardware, 1 ou 2 sobre o uso mais frequente do servidor e o instalador já coloca no lugar um arquivo .config bem próximo do que ele precisa. Duas ou 3 perguntas na hora de criar o banco de dados (resultando num monte de SETs que usam essas perguntas e a configuração do servidor para chegar num conjunto de opções decente) também facilitariam muito as coisas para o DBA. Claro, isso ainda fica meio longe do mundo perfeito do servidor auto-configurável, mas tentar ir nessa direção (ao menos para ir para o mesmo lado dos que estão quase lá) não seria nada mal... 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. A questão é se vale jogar o valor geral para o alto, ou dar um aumento moderado geral e só jogar para bem mais alto determinadas tabelas. E se é necessário 1000 como você propõe, ou no máximo 300 como o Euler propôs. 1000 numa tabela pequena gera um pouco de desperdício, mas não é muito, já que a tabela é pequena e o processamento sobre ela não é grande coisa. Agora, 300 numa tabela grande tem boa chance de ser um desastre. Bom, estamos de novo em julgamentos subjetivos, tentemos colocar alguma objetividade: Já que as discussões anteriores sobre aumentar esse valor acabaram por falta de provas de que um novo valor seria mais interessante, mesmo que contrário aos que já testaram com valores maiores e encontraram melhores resultados, que tal propor a essas mentes tão convictas que montem um ambiente em que esses valores proporcionem um desempenho tão maravilhoso quando comparado ao resultado de nossos experimentos? O ônus da prova cabe a quem afirma. Quem afirmou que 10 é um bom valor a ponto de não mudá-lo nem atendendo a pedidos, que prove. Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/23 George [EMAIL PROTECTED]: 1. Criar um esquema de eventos 2. Mover a tabela eventos para este schema (cli, eqp, dta, eve, dta, hms). 3. Criar tabelas (cli_XX) de herança da tabela de eventos no schema eventos 4. Criar tabelas (eqp_XX) de herança das tabelas cli_XX no schema 5. Criar dinamicamente as tabelas de herança no cadastro de clientes e equipamentos através de trigger; 6. Alterar todas as funções e trigger para realizar tratamento dinamicamente. 7. Alterar a regra de negócio para o banco de dados em relaçãoa eventos. Impressão minha ou você reimplementou particionamento de tabelas na raça? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Não, usei inherits ! Exemplo Create tabpai1 (cod bigint, tip char(3), cba varchar(100)); Create tabfil1 () inherits (tabpai1); Create tabfil2 () inherits (tabpai2); Insert into tabfil1 (1234456789,'001',' AAABACADAEAFAGAHAJAIAKALAPANAGAFARTACADAEAGA'); Insert into tabfil1 (1234456789,'002',' AAABACADAEAFAGAHAJAIAKALAPANAGAFARTACADAEAGA'); Veja os resultados de cada tabela. No meu caso na tabela cliente tenho uma trigger que verifica se existe a tabela e crio dinamicamente no schema eventos a tabela CLI_X. O X é o código do cliente. Exemplo da parte da trigger: if not exists(select tablename from pg_tables where schemaname = 'eventos' and tablename = trim(cli||new.cod::char(5)) then v_exec = 'Create table trim(cli||new.cod::varchar) () inherits (eventos)'; execute v_exec; end if; Por isso quando entra no sistema cliente dependendo do código irá saber qual tabela chamar. Imagine isso no cadastro de produtos e vc criando uma tabela de extrato para cada produto e esta mesma tabela atualziando seu saldo ! Espero ter ajudado. Abraços George - Original Message - From: Leandro DUTRA [EMAIL PROTECTED] To: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Sent: Thursday, October 23, 2008 6:19 PM Subject: Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE 2008/10/23 George [EMAIL PROTECTED]: 1. Criar um esquema de eventos 2. Mover a tabela eventos para este schema (cli, eqp, dta, eve, dta, hms). 3. Criar tabelas (cli_XX) de herança da tabela de eventos no schema eventos 4. Criar tabelas (eqp_XX) de herança das tabelas cli_XX no schema 5. Criar dinamicamente as tabelas de herança no cadastro de clientes e equipamentos através de trigger; 6. Alterar todas as funções e trigger para realizar tratamento dinamicamente. 7. Alterar a regra de negócio para o banco de dados em relaçãoa eventos. Impressão minha ou você reimplementou particionamento de tabelas na raça? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Fabrízio, O otimizador do Postgres costuma fazer péssimas escolhas em tabelas grandes quando o default_statistics_target é muito baixo. Cansei de ver ele apanhar mais do que cão sem dono do SQL Server por escolher planos ridículos quando deixei esse valor padrão. Deixe seu default_statistics_target=1000 e veja se melhora. Atenciosamente, Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Mozart Hasse escreveu: O otimizador do Postgres costuma fazer péssimas escolhas em tabelas grandes quando o default_statistics_target é muito baixo. Cansei de ver ele apanhar mais do que cão sem dono do SQL Server por escolher planos ridículos quando deixei esse valor padrão. 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. 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). -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
2008/10/22 Euler Taveira de Oliveira [EMAIL PROTECTED]: Mozart Hasse escreveu: 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). Euler é cultura! :-) E o Mozart levanta um casos interessantes. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Estranho com Query Lentas e ANALYZE
Olá, Quando você seta para -1 você esta avisando o analyze para ele usar o valor padrão para default_statistics_target=10. Eu nunca tive nenhum problema parecido. Mas me parece no mínimo interessante esta sua questão. Assim que tiver um tempinho vou tentar simular alguma coisa do tipo. Você tentou aumentar os valores do default_statistics_target para um valor maior destas colunas, como, por exemplo 20 ou 30 e refazer os testes com as consultas e verificar o comportamento das consultas? Estas suas colunas que estavam com valor 0 desabilitado, como é a distribuição dos dados? E qual versão do PostgreSQL você está utilizando? []s 2008/10/21 Fabrízio de Royes Mello [EMAIL PROTECTED]: Caros Colegas, Há algum tempo estava analisando uma base de dados e verifiquei que diversas colunas das tabelas dessa base estavam com a coleta de estatisticas desabilitada. Na saida de um dump da estrutura da base encontrei algo como: ALTER TABLE tabela ALTER COLUMN coluna SET STATISTICS 0; Essa desativação não estava em TODAS colunas das tabelas da base de dados, verifiquei isso facilmente com alguns SQLs, dentre eles: SELECT * FROM pg_attribute WHERE attstattarget = 0 AND attnum 0; Fiquei surpreso que essas estatisticas estivessem desabilitadas então resolvi logo habilitadas (colocando o valor -1 pra buscar da configuração do postgresql.conf conforme documentação oficial) mas o que fiquei mais surpreso ainda foi com o resultado... foi desastroso pois degradou a performance das queries... e naquele final de semana, oportunamente, foi executado um REINDEX DATABASE e após um VACUUM ANALYZE, este último é executado diariamente... Verifiquei todas configurações (shared_mem, work_mem, effetive_cache_size, etc...) para ver se conseguiria mudar o resultado pois uma simples consulta que demorava de ~3seg começou a demorar ~907seg... muita diferença não é mesmo... Com isso fui fazer uns EXPLAINs das queries no servidor que habilitei as estatisticas para comparar com outro onde as estatisticas ainda estavam desabilitadas e, É ÓBVIO, deu diferença no resultado dos EXPLAINs... até ai sem problemas, o problema é que com a estatisticas HABILITADAS ficou MUITO PIOR... será que não deveria ficar melhor?? A diferença significativa no resultado dos EXPLAINs é que na base que as estatisticas estavam desabilitadas no resultado tinha um BITMAP HEAP SCAN resultando num custo bem menor que o da base que as estatisticas estavam habilitadas o qual não fazia esse bitmap_scan, fazendo um index_scan normal... e não se preocupem que verifiquei e NOS 2 SERVIDORES as configurações dos métodos do planejador estão iguais: enable_bitmapscan = on enable_hashagg = on enable_hashjoin = on enable_indexscan = on enable_mergejoin = on enable_nestloop = on enable_seqscan = off enable_sort = on enable_tidscan = off Com isso tudo, sem entender nada e ter levado uma surra do elefantinho resolvi tomar a seguinte medida DRÁSTICA: 1) Desabilitei as COLUNAS que assim estavam antes do meu ato heróico de habilitalas (deixei a base de dados no estado original) 2) Rodei um DELETE na pg_statistic... isso mesmo... um DELETE nela... 3) Rodei um ANALYZE na base de dados... Meus amigos adivinhem o resultado... as queries voltaram ao normal... exatamente como eram antes... tudo rápido q é uma beleza... a query que demorava ~907seg antes desse procedimento voltou a demorar apenas ~3seg... Agora gostaria de saber se algum dos colegas sabe o porque desse comportamento, no mínimo estranho e/ou duvidoso, do planejador do nosso amigo PostgreSQL. Cordialmente, -- Fabrízio de Royes Mello Coordenador Desenvolvimento de Software [EMAIL PROTECTED] DBSeller Informática Ltda. - http://www.dbseller.com.br (51) 3076-5101 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- João Paulo www.dextra.com.br/postgres PostgreSQL ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
