Olá Mozart, Eu faço algo parecido com o que você mencionou em mais de uma situação, e o resultado é muito satisfatório. Você faz os 3000 mil registros dentro de uma única transação sem commit? E se você fizer cada registro uma transação?! Você está com o vacuum / reindex atualizado nessa base? Há mais algum processo que rode nesse servidor além do Postgres?
Os testes que eu fiz com Postgres rodando em Windows não me foram nenhum pouco satisfatório. A mesma máquina, rodando Linux, me foi até 10 vezes melhor. Existe possibilidade da migração? Att, Rafael Domiciano 2009/11/9 Mozart Hasse <[email protected]> > Dileto Dutra, > > > 2009/10/30 Mozart Hasse <[email protected]>: > > > Uma VIEW totalizando saldos sobre uma tabela de 130000 > registros?!?!?!?! > > > Meu cliente não tem tempo ocioso para esperar servidor SQL nenhum ficar > > > somando essa tralha cada vez que ele resolver consultar o saldo de > alguma > > > coisa. A consulta de saldos é muito mais frequente do que quaisquer > > > atualizações. > > > Parece um caso para visões materializadas. > > Sim, e no meu entendimento é na prática o que estou fazendo. Cada > alteração na tabela principal atualiza via triggers os saldos em 3 tabelas > auxiliares, que nada mais são do que a totalização de saldos dos registros > originais. > > O problema aqui é que o Postgres não me dá opção de fazer isso com > desempenho satisfatório no caso das exclusões em bloco (3000 registros, por > exemplo), pois a bendita trigger ON EACH ROW dispara 3000 vezes, uma para > cada > registro. Se eu apelar para trigger disparando por comando (ON EACH > STATEMENT), fico igualmente com um problema de lentidão, pois qualquer > atualização implicaria em recalcular os saldos da tabela inteira, já que o > Postgres não sabe me dizer quais registros foram alterados. > > No momento as opções do cliente são: > 1. Conformar-se com a lentidão do Postgres. > 2. Trocar para SQL Server. > 3. Esperar a gente resolver alterar a aplicação inteira para usar uma > stored > procedure (function) para excluir um ou mais registros ao invés de um > inocente comando DELETE, com todas as implicações e complicações de > segurança e manutenção que isso irá nos causar. Comparando com o custo de > colocar SQL Server no cliente, não tenho nem dúvida que isso não vai > acontecer. > > Atenciosamente, > > Mozart Hasse > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
