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
