Telles, > Meu caro Mozart, você escreveu um e-mail longo, mas não colocou as > principais informações.
Obrigado por colaborar com base na informação disponível. > Não tenho como adivinhar que tipo de > operação você está fazendo, se é uma operação do tipo "fechamento de > mês" onde vários dados são totalizados e transferidos de uma tabela > para outra, se é um cálculo mensal do tipo folha de pagamento ou se é > uma carga de dados vindo de outra fonte via txt por exemplo. Basta assumir o pior caso que é o que você aparentemente usou como base: tenho todas essas coisas e mais algumas. > - COPY é melhor que multiplos INSERTs, que é melhor que INSERTS c/ > PREPARED STATEMENTs, que são melhores que INSERTs individuais. > - INSERT é melhor que DELETE (escrevi um artigo sobre isso em: > http://www.midstorm.org/~telles/2007/11/29/nao-use-delete-use-insert/) > - Após a carga, sempre rode um vacuum analize nas tabelas afetadas > - Use cursores se estiver estourando a sua memória! ok > - Nenhum processo em lote deve ser executado via CLIENT/SERVER, rode > tudo via PL dentro do banco que você vai ter uma performance > absurdamente melhor; Obrigado por informar, mesmo que viole meus requisitos. > - Se você puder agendar sua rotina em lote para um horário mais calmo, > pense em fazer uma configuração específica de desempenho para a carga, > por exemplo diminuindo o número de conexões e aumentando a memória > para uma conexão individual, Obrigado por informar, mesmo que viole meus requisitos. Não quero mexer no servidor para rodar um script inocente. Sim, eu me conformo com o desempenho possível dadas as limitações que indiquei. > - Se tiver que fazer uma carga de dados em TXT com possíveis > problemas... considere trazer tudo para uma tabela burra (uma tabela > TEMPORÁRIA com um campo TEXT sem PK) para receber os dados > inicialmente dentro do banco. Depois de carregar todos os dados na > tabela burra, você poderá tratar os dados com SQL e mover os registros > problemáticos para outra área e aí sim transferir os registros da sua > tabela burra para os locais corretos. > - Aprenda a fazer o tratamento de erros em PL, Sim, realmente, só que eu gostaria de uma solução mais simples e prática. Não quero montar um script ou um programa que monte um script fazendo isso para cada tabela quando se tratar de carga. Isso exige conhecimento da estrutura, chaves, tipos de dados e integridade referencial. No meu caso é muito esforço em qualificação e pré-processamento para um inocente script de carga, que por sinal eu gostaria muito de *não* mexer. > - Remova constraints e índices quando for fazer grandes cargas e deixe > para reconstruí-los no final. A lista de constraints é, no meu caso, imprevisível. O número de índices e constraints afetados é enorme, os passos extras necessários para tirar e por essas constraints e índices é muito inconveninente. O tempo que o servidor ficaria quase que totalmente inacessível reconstruindo-os é bastante indesejado. > - Aprenda a utilizar COMMIT, ROLLBACK e SAVEPOINT corretamente e > estimar de quantos em quantos registros realizar um COMMIT. Isso depende da configuração do servidor. Não quero depender disso. Obrigado pelas dicas, mesmo que não sejam bem o que eu estava procurando. Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
