SEQUÊNCIA
- Melhor Desempenho em Big Update no Postgresql Você está aqui
- Melhor Desempenho em Big Update no Postgresql (Continuação)
- Melhor Desempenho em Big Update no Postgresql (Adicional)
VAMOS AO CARD
Eventualmente precisamos fazer um update no banco afetando uma tabela inteira, ou quase inteira. Isso resulta em um processamento caro.
Podemos melhorar este processamento apenas removendo os índices da tabela e depois recriando-os ao final. E não estou falando dos índices relacionados as colunas que estão presentes no seu update. Estou falando de todo e qualquer índice presente na tabela.
Isto pois dentro de uma transação o update de cada tupla representa na verdade um insert de uma nova tupla atualizada e a marcação da tupla antiga como "old" (a ser removida posteriormente). E toda tupla criada precisa ser indexada. Dessa forma, um update que afete uma tabela inteira (ou maior parte dela) com certeza precisará atualizar intensamente várias páginas de índice.
Em uma necessidade pessoal, fazer apenas o update direto me custou 70 minutos. Enquanto que ao remover os índices (15 presentes no caso em questão), realizar o update, e então recriar os índices, me custou 32 minutos ao total. Uma diferença grande para uma solução tão rápida de se escrever.
Resumindo, é mais simples um índice ser completamente refeito de uma só vez, do que cada tupla por vez, certo!?
Fonte: http://dba.stackexchange.com/questions/41059/optimizing-bulk-update-performance-in-postgresql Show archive.org snapshot
UPDATE route
If you (have to) go the UPDATE route, drop any index that is not needed during the update and recreate it afterwards. It is much cheaper to create an index in one piece than to update it for every individual row.
