Marcio, > Utilizamos o Postgres na empresa há dois anos, em um sistema completo > (ERP).
Usamos desde que o PostgreSQL 7 era novidade. > Acontece que de uns tempo pra cá o sistema se tornou muito lento. As > consultas ficaram lentas. O cadastro de notas fiscais que antes era bem > rápido, agora se tornou muito lento nas pesquisas e nas inclusões. > Eliminamos todos os problemas de redes e infraestrutura, chegando a > conclusão que se trata do banco de dados. Sim, já vi isso acontecer inúmeras vezes com o PostgreSQL. Por via das dúvidas, é bom olhar se tua aplicação não está fazendo nenhuma bobagem, como trazer todos os registros de movimento para a estação em alguma consulta. > O DBA comentou que a solução seria a separação dos índices do banco de > dados. Isso *e*r*a* boa idéia antes da popularização dos discos com espelhamento. Agora você consegue efeito melhor com RAID 5, 10 & cia. > ... e não tenho certeza que isso dará um desempenho maior no sistema. Meu palpite é que vai ser difícil ver alguma diferença. > Gostaria de saber se alguém já utiliza essa solução de índices separados e > se realmente vale arriscar todo arranjo já feito para se montar algo > assim. Sendo *bem* otimista, julgo muito pouco provável que valha o esforço. Como sugestão, faça o seguinte: * confirme se o gargalo do servidor é disco ou processador. Provavelmente é disco, mas o modo como a aplicação foi feita influencia bastante e pode revelar uma grande surpresa; * confira seus parâmetros de configuração para ter certeza de que está usando toda a memória disponível no servidor para o PostgreSQL (deixando é claro uma sobrinha para o sistema operacional). O instalador do 8.4 vem com um configurador automático, se nem mexeu no seu postgresql.conf, sem dúvida ele é um bom começo; * _entupa_ suas tabelas de índices (a minha de notas tem mais de 50), pelo menos dois por chave estrangeira mais as combinações de consultas frequentes. Não, não acho que a gravação será responsável pelo seu gargalo nem com o dobro do que eu costumo colocar; * migre sua base pelo menos para 8.4, tem muitas otimizações que tornam o PostgreSQL menos sofrível em ERPs; * pense muito bem antes de mexer no autovaccum, e só o desligue se tiver certeza do que está fazendo; * mexa nas configurações da sua base para ver se o otimizador faz menos bobagens. Eu ponho RANDOM_PAGE_COST em 2 e mexo também nos outros fatores, além de meter o default_statistics_target lá em cima (meu valor favorito é 1000) para todas as tabelas por padrão. Só o analista da tua aplicação vai saber no que mexer em função do estilo das suas consultas, mas vou te adiantando que isso funcionou muito bem (tornou o PostgreSQL viável) como regra geral para mim. Uma boa lista de parâmetros a pesquisar está aqui: http://developer.postgresql.org/pgdocs/postgres/runtime-config-query.html * último recurso considerando PostgreSQL como opção: particione suas tabelas, deixando os movimentos mais antigos em tabelas auxiliares, mantendo assim suas tabelas de movimentação pequenas e seu esforço de manutenção bem grande. É horrível de criar e manter, porém deixa o desempenho num patamar aceitável. Boa sorte, Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
