Em 07/02/16, Saraiva Silva<matheus.sara...@gmail.com> escreveu:
Pois é, meu interesse é porque eu tenho funções que fazem inserções e
updates. Como não é possível saber quais colunas o usuário irá atualizar,
então minha função de atualização tem parâmetros para todas as colunas. Mas
em uma tabela com 15 colunas, e o usuário alterar apenas uma coluna de um
registro, a função vai desperdiçar recursos. Pois ela irá atualizar todas
as outras colunas com dados repetidos.
O desafio é atualizar somente as colunas que realmente foram alteradas.
Como exemplo uma função que faz update em uma tabela de CEPs:
http://paste.ubuntu.com/14962205/
Como fazer a função atualizar somente as colunas alteradas?
Creio que você deveria dar uma estudada no modelo MVCC utilizado pelo
PostgreSQL.
http://www.postgresql.org/docs/current/interactive/mvcc.html
A cada updade uma nova versão do registro é gerada, ou seja, o
possível desperdício de recursos é mínimo frente a reescrever todo o
registro.
Queria apenas complementar a informação do Osvaldo, há sim dois impactos
que não são negligenciáveis neste caso.
Com relação à escrita nas tabelas e MVCC, existe uma exceção a essa
regra da nova tupla. para colunas que ultrapassam o mínimo previsto para
que os dados caiam numa tabela TOAST (a partir de 2kiB na compilação
padrão). Numa coluna desse tipo, em ambos os casos, se o valor dentro do
UPDATE for o mesmo, ou se a coluna não for listada no comando, a tabela
TOAST permanece inalterada.
O maior impacto que vejo para desempenho, a partir da versão 9.4, as
porções não modificadas de um UPDATE não são escritos no WAL:
http://www.postgresql.org/docs/9.4/static/release-9-4.html
Isso pode reduzir *muito* a quantidade de escrita e de dados a guardar e
replicar para casos de updates em massa.
Uma solução para o colega da pergunta original é de fazer várias tabelas
com menos colunas. Neste caso, a função vai fazer UPDATE somente nas
tabelas que tiveram colunas alteradas por exemplo. Claro que isso tem um
custo para fazer junções depois, mas aí cada caso precisa ser analisado.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
