2008/12/12 Mozart Hasse <[email protected]>: > 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.
>> - 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. > Então... seria bom rever seus requisitos... a não ser que você esteja munido que uma varinha mágica, não vai encontrar nenhuma forma de lidar com isso de outra forma. Eu pelo menos não acredito muito em fórmulas mágicas, mesmo porquê eu cobro bem caro para arrumar as caquinhas que as ferramentas automagicas fazem. >> - 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. Bom, se você não quer mexer.. faça uma coisa. Não mexa mesmo. Não coloque nada no meio para tentar amenizar o problema. Aprenda apena a conviver com ele. > >> - 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. Você pode via SQL guardar extrair todas as definições dos constraints e índices do dicionário de dados (vide information_schema) e fazer tudo de forma automática. > >> - 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. > Isso é SQL, não depende do seu SO, depende de estudar!!! > Obrigado pelas dicas, mesmo que não sejam bem o que eu estava procurando. Existe um ditado que diz que "quem não sabe o que procura não compreende o que encontra". Talvez você esteja procurando resolver o problema da forma errada, ou melhor ainda... talvez seja melhor deixar o problema lá, quietinho no canto dele, já que não está disposto a esquarteja-lo. Se encontrar uma fórmula mágica no caminho - pense que os chatos as vezes te salvam de algumas roubadas significativas - tome muito cuidado antes de fazer qualquer coisa, teste bem e veja se é exatamente o que você esperava. []s Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [email protected] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
