O Postgresql difere de outros DBMSs, pois durante a operação UPDATE, as alterações na linha existente não ocorrem e, em vez disso, é feita uma cópia da linha que difere do original com os valores das colunas afetadas pela atualização - eles são antigos no original e alterados na cópia. Essa abordagem, por um lado, permite evitar bloqueios durante a execução de solicitações de leitura e gravação e, por outro lado, cria a necessidade de limpar constantemente versões antigas de linhas que ninguém nunca lerá. Em conexão com esse recurso de arquitetura, geralmente surge a pergunta sobre o que acontecerá se você precisar armazenar no banco de dados algo como a hora do último acesso aos dados que, caso contrário, não será alterado. Ele responderá ao desempenho? Isso levará a uma constante reestruturação dos índices?
Em resumo, sim, o Copy On Write não irá a lugar algum, mas em muitos casos os índices não podem ser reconstruídos, graças ao HOT.
As tuplas de heap only, também conhecidas como HOT, são uma otimização usada pelo Postgres para reduzir a quantidade de E / S necessária para atualizações. Devido ao MVCC, uma atualização no Postgres consiste em encontrar uma linha para a atualização e inserir novas versões da linha no banco de dados. A principal desvantagem deste procedimento é a necessidade de adicionar novamente uma linha a cada índice.
Isso requer muito mais E / S porque a linha precisa ser reinserida em cada índice da tabela. A necessidade de reinserir surge porque a posição física da nova versão de uma linha no disco é diferente da posição física da versão antiga.
Para reduzir a quantidade de E / S necessária para UPDATE, a equipe do Postgres adicionou HOT ao Postgres. A ideia por trás do HOT é relativamente simples. Ao atualizar a linha, se possível, o Postgres colocará uma nova cópia da linha imediatamente após a cópia antiga da linha. Além disso, na cópia antiga da string, um rótulo especial é afixado para que o Postgres saiba que a nova cópia da string é imediatamente após a antiga. Portanto, a atualização de todos os índices não é necessária.
Durante a varredura por índice para a qual uma nova cópia da sequência passa, o filtro do Postgres encontrará a cópia antiga da sequência. Como existe uma etiqueta especial na cópia antiga da linha, o Postgres entenderá que a nova cópia da linha está localizada imediatamente após a antiga e encontrará a nova versão e a utilizará. Acontece que o Postgres nesses casos pode se comportar como se todos os índices apontassem para uma nova cópia da string e eles não precisassem ser reconstruídos.
Agora, o HOT está envolvido apenas quando apenas colunas não indexáveis estão envolvidas na atualização. Se pelo menos uma coluna participante da atualização estiver incluída no índice, o HOT não poderá ser aplicado. Nesse caso, há vários problemas com o uso do HOT. Por exemplo, quando o índice na coluna que precisa ser atualizado é indexado por uma varredura e a cópia antiga da linha cai no predicado da varredura, mas a nova não. Nessa situação, o Postgres tentará usar o índice para encontrar rapidamente todas as linhas adequadas ao predicado de consulta e, no caso de colunas que foram atualizadas usando o HOT, produzirá uma nova cópia da linha que não corresponde ao predicado de consulta. Devido a essa limitação (que o HOT não funciona quando as colunas indexáveis estão incluídas na atualização), o Postgres pode garantir que, quando ele tentar encontrar linhas adequadas ao predicado pelo qual o índice é passado, se o predicado corresponder à versão antiga da linha, a nova versão da linha também combina com ele e vice-versa.
Atualmente em desenvolvimento, há uma extensão HOT denominada WARM, que também funciona ao atualizar colunas nas quais os índices são criados. A idéia por trás do WARM é colocar uma nova linha imediatamente após a antiga e atualizar a linha para índices que mudaram de coluna. Isso complica bastante a situação descrita, porque agora o Postgres precisa de uma maneira de determinar se a linha passa no filtro para o índice ou não.
PS No artigo original, o mecanismo HOT é descrito, mas aqui temos em mente o mecanismo no qual heap apenas tuplas estão envolvidas, e o próprio termo tem um significado separado.
A tupla somente da pilha é apenas uma nova versão da linha. Por mais estranho que pareça, um Heap é uma tabela, e Heap significa apenas que essa linha só pode ser encontrada pela cadeia que leva da versão mais antiga da linha chamada raiz.