Dúvida: Deparei-me com uma trigger em Postgres que para um determinado caso está horrivelmente lenta. O cenário é o seguinte: temos uma tabela de lançamentos, com uso pesado e simultâneo, que atualiza via trigger uma tabela de saldos, usando trigger functions do tipo ON EACH ROW, que determinam a diferença de valores entre o OLD e o NEW para saber o que atualizar na tabela de saldos. Isso funciona de maneira aceitável com inclusões e alterações, que normalmente são individuais ou têm um esquema próprio para aumentar desempenho. Também funciona de maneira razoável quando eu excluo até 50 registros de uma vez. O problema é que a tabela tem 130000 registros e o cliente agora resolveu mandar várias atualizações com média de 3000 registros de uma vez, o que para um trigger do tipo ON EACH ROW está sendo um desastre. O SQL Server tem um modo de indicar o que foi modificado através das tabelas virtuais 'inserted' e 'deleted', por isso a mesma rotina em SQL Server (ceteris paribus) exclui os 3000 registros e executa via trigger os recálculos necessários em 5 ou 6 segundos, enquanto que o Postgres leva *horas* (mais de 10, não tivemos paciência de cronometrar) recalculando registro a registro com o ON EACH ROW.
Alguém conhece um jeito de simular as tabelas virtuais 'inserted' e 'deleted' no postgres para eu usar um ON EACH STATEMENT? A documentação não me pareceu nada animadora: http://www.postgresql.org/docs/8.4/static/trigger-definition.html "Statement-level triggers do not currently have any way to examine the individual row(s) modified by the statement." Há alguma previsão de implementar isso no futuro? Adiantando: mover os dados para uma tabela auxiliar (com BEFORE DELETE ON EACH ROW) para depois processá-los uma só vez com AFTER DELETE ON EACH STATEMENT tem diversos inconvenientes, pois há validações ON EACH STATEMENT que eu preciso fazer antes de autorizar a alteração e eu teria de colocar campos extras na tabela auxiliar para evitar que transações concorrentes misturem registros umas das outras. Teoricamente até funciona, mas ainda deixaria o processo lento e mais complicado do que já é. Atenciosamente, Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
