> Informação é sempre bom, mas há limitações: Sem dúvidas
>> 1) habilito consultas lentas no log (log_min_duration_statement = 1s >> por exemplo); analiso com o PgFouine e vou otimizando pouco a pouco. > > Há muitas situações em que o que pesa não são as consultas lentas, mas > consultas rápidas e freqüentes. E não é por serem (relativamente) rápidas que > não precisem de um carinho nos índices de quando em vez… Sem dúvida! Mas um bom ponto de partida para otimizações é trabalhar sobre as consultas lentas, que são aquelas que os usuários percebem em um sistema. Claro que uma otimização completa precisaria olhar todas as consultas, mas dependendo do sistema, isso pode ser excessivamente trabalhoso/caro de se fazer. Então, o que proponho é um trabalho ideal. O ótimo é inimigo do bom :) >> 2) dou uma olhada na pg_statio_user_indexes e vejo como está o uso dos >> índices existentes; se algum índice composto tiver baixa taxa de uso, >> pode estar precisando de otimização ou remoção. > > Outra informação interessante, mas não fala muito sobre os índices que não > existem e precisariam existir. Isso está coberto pela informação anterior (consultas lentas). > Combinando essas duas informações dá para cobrir muito de muitos > sistemas, mas não tudo. Sem sombra de dúvidas! >> Para sistemas em implementação, se estiver usando um ORM, dá pra catar >> a lista de consultas pré-formatadas e trabalhar em cima delas. > > Se estiver usando ORM, dá para sentar na sarjeta e chorar… :-( Nem sempre. ORMs podem ser bem utilizados. O que não dá é pra "entregar tudo" para o ORM, deixar que ele se vire com todos os objetos. Um banco bem desenhado junto a um ORM bem configurado pode facilitar a vida do DBA de produção e também do programador. []s Flavio Gurgel _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
