2009/10/29 Mozart Hasse <mozart.ha...@usa.net>: > > 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.
Um dos motivos por que eu prefiro não usar tabelas cujos dados são resultados de cálculos de outras tabelas. Prefiro usar VIEWs. > 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. Não me parece tanto assim. Aqui vão algumas perguntas: 1) Quão complexos são esses cálculos? 2) Quantas consultas em outras tabelas tem que ser feitas nesses cálculos? 3) Já passaste essas consultas por seus devidos EXPLAIN para analisar como elas estão sendo planejadas? 4) Como está a sua work_mem e parâmetros relacionados de memória? Como estão seus parâmetros de checkpoints? Será que o PG não está gastando muito tempo fazendo checkpoints, ou tendo pouca memória para trabalhar? 5) Como é a sua configuração de disco? Logs estão em discos separados? Tabelas mais usadas, como essa de saldo, estão em tablespaces separados? > 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. Tem algo errado aí. Será que isso é um caso da aplicação estar sendo desenvolvida (e otimizada) no SQL Server e portada sem o mesmo cuidado para PG? Se os cálculos são complexos e tem que ser feitos ANTES dos resultados serem enviados ao disco e transação COMMITted, como pode o SQL Server fazer em 5 segundos? Se o SQL Server estiver apenas criando as tabelas "virtuais" e retornando controle ao usuário, para depois executar a checagem e escrita em disco usando as tabelas virtuais, então o comportamento está errado, de acordo com o que você disse que não pode acontecer abaixo (usando uma tabela separada) Roberto _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
