Valeu pessoal, Deixa dar um resumo do meu cenário para ficar mais claro o problema. Conversando com o gerente do projeto acho que achei o problema ... é tudo ;-) e o sistema teria que ser todo reescrito:
Deixa eu contar parte da minha história: Nós temos uma base de dados de espécies botânicas, e como vocês deve lembrar do seu tempo de ginásio, que uma planta possui um reino, um filo, uma família, um gênero, uma espécie, um tipo, ..... Isso chama-se 'taxon'. E apesar de não ser TÃO complicado é chato de trabalhar pois são informações que precisam ser processadas com algoritimos de árvore. Pra simplificar o cenário, basicamente eu tenho duas tabelas (é muito mais do que isso, mas como eu disse é só pra simplificar). Dadas essas duas tabelas: Uma tem essa hierarquia, e a outra são dados da espécie em si. O problema começa quando eu preciso listar minhas espécies. Não basta apenas dar um SELECT na tabela espécies, é preciso fazer uma varredura na tabela de taxons para listar toda a 'hierarquia genealógica' a qual a aquela espécie pertence. O resultado... o processamento é loooooooongo!!! E não para por ai. Se um taxon desse é modificado, por algum motivo a situação é mais complicada, pois eu preciso inserir/editar vários itens na tabela de taxons. Isso é uma loucura e gera um caos, produzido por inúmeras triggers e store-procedures. E assim começa a penitencia, mas tem mais, eu recebo diariamente um lote de dados em um tabelão que precisa ser desmembrado, filtrado e ordenado para que possa se enquadrar neste perfíl e depois ser efetivamente importado. Tudo isso tem 'chupado' recursos do meu sistema. Em 19/06/07, Fabio Telles <[EMAIL PROTECTED]> escreveu:
Em 18/06/07, Welington R. Braga<[EMAIL PROTECTED]> escreveu: > Valeu Euler, > > Já monitorei, mas nada indica qual processador esta em uso e o problema > continua: > > Eu tenho uma consulta que roda periodicamente importando dados de uma tabela > para outra fazendo apenas algumas conversões de dados e numa quantidade na > ordem de milhares de registros. Após executar essa consulta o acesso a base > principal fica muito lento. > > O problema pelo que percebi é que quando a consulta roda, o banco joga todos > os registros para memória e lá ficam até ocorrer um commit. Sim, isso é normal. Sempre que vamos rodar rotinas em lote, temos que tomar alguns cuidados para não arriar o banco: - Desativar índices e chaves - Tentar usar COPY ao invés de INSERT - Tentar usar TRUNCATE ao invés de DELETE - Tentar usar tableas temporárias ao invés de um commit no final do processo. - Tentar paralelizar as operações longas utilizando mais de um processo separado - Tentar particionar tabelas grandes - Distribuir melhor os dados em grupos físicos e lógicos de discos distintos. Particularmente, parece que o seu commit vai consumir muito recurso no final. Cada caso é um caso, mas movimentar milhões de linhas e dar um commit só no final acaba com os recursos de qualquer SGDB, até do DB2. Este tipo de situação deve ser evitado a todo custo. Existem várias técnicas para evitar isso. Dá bem mais trabalho, mas o desempenho é fantástico. Bom, de qualquer forma, parece que seu PostgreSQL está ótimo, mas seu processo precisa ser otimizado. []s Fábio Telles > -- site: http://www.midstorm.org/~telles/ e-mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] sip:[EMAIL PROTECTED] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
-- Welington Rodrigues Braga -------------- Web: http://gtk-br.welrbraga.t5.com.br MSN: welrbraga[*]msn·com Gtalk: welrbraga[*]gmail·com Yahoo / Skype: welrbraga ICQ: 52789331 "Em tudo somos atribulados, porém não angustiados; perplexos, porém não desanimados; perseguidos, porém não desamparados; abatidos, porém não destruídos;" - 2Co 4:8,9
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
