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
