Postgresql difiere de otros DBMS en que durante la operación ACTUALIZACIÓN, no se producen cambios en la fila existente y, en su lugar, se realiza una copia de la fila que difiere del original con los valores de las columnas afectadas por la actualización: son antiguos en el original y cambiaron en la copia. Este enfoque, por un lado, le permite evitar el bloqueo al ejecutar solicitudes de lectura y escritura, y por otro lado, crea la necesidad de borrar constantemente versiones antiguas de cadenas que nadie leerá nunca. En relación con esta característica arquitectónica, a menudo surge la pregunta de qué sucederá si necesita almacenar en la base de datos algo así como el momento del último acceso a los datos que de otro modo no cambiaría. ¿Responderá al rendimiento? ¿Conducirá a una reestructuración constante de los índices?
En resumen, sí, Copy On Write no irá a ninguna parte, pero en muchos casos los índices no se pueden reconstruir, gracias a HOT.
Heup only tuples, también conocido como HOT, es una optimización que Postgres usa para reducir la cantidad de E / S requerida para las actualizaciones. Debido a MVCC, una actualización en Postgres consiste en encontrar una fila para la actualización e insertar nuevas versiones de la fila en la base de datos. El principal inconveniente de este procedimiento es la necesidad de volver a agregar una fila a cada índice.
Esto requiere mucha más E / S porque la fila debe reinsertarse en cada índice de la tabla. La necesidad de reinsertar surge porque la posición física de la nueva versión de una línea en el disco es diferente de la posición física de la versión anterior.
Para reducir la cantidad de E / S requerida para ACTUALIZAR, el equipo de Postgres agregó HOT a Postgres. La idea detrás de HOT es relativamente simple. Al actualizar la línea, si es posible, Postgres pondrá una nueva copia de la línea inmediatamente después de la copia anterior de la línea. Además, en la copia anterior de la cadena, se coloca una etiqueta especial para que Postgres sepa que la nueva copia de la cadena se encuentra inmediatamente después de la anterior. Por lo tanto, no es necesario actualizar todos los índices.
Durante el escaneo por índice para el que pasa una nueva copia de la cadena, el filtro de Postgres encontrará la copia anterior de la cadena. Dado que hay una etiqueta especial en la copia anterior de la línea, Postgres comprenderá que la nueva copia de la línea se encuentra inmediatamente después de la anterior y encontrará la nueva versión y la usará. Resulta que Postgres en tales casos puede comportarse como si todos los índices apuntaran a una nueva copia de la cadena, y no necesitan ser reconstruidos.
Ahora HOT solo está involucrado cuando solo las columnas no indexables están involucradas en la actualización. Si al menos una columna que participa en la actualización se incluye en el índice, HOT no se puede aplicar. En este caso, hay varios problemas con el uso de HOT. Por ejemplo, cuando el índice de la columna que debe actualizarse se indexa mediante un escaneo y la copia anterior de la línea cae en el predicado del escaneo, pero el nuevo no. En esta situación, Postgres intentará usar el índice para encontrar rápidamente todas las filas que sean adecuadas para el predicado de consulta, y en el caso de las columnas que se actualizaron usando HOT, producirá una nueva copia de la fila que no coincide con el predicado de consulta. Debido a esta limitación (que HOT no funciona cuando se incluyen columnas indexables en la actualización), Postgres puede garantizar que cuando intenta encontrar filas que sean adecuadas para el predicado a través del cual se pasa el índice, entonces si el predicado coincide con la versión anterior de la fila, entonces la nueva versión de la fila también le queda bien y viceversa.
Actualmente se encuentra en desarrollo una extensión HOT llamada WARM, que también funciona al actualizar columnas en las que se crean índices. La idea detrás de WARM es colocar una nueva fila inmediatamente después de la anterior y actualizar la fila para los índices que han cambiado las columnas. Esto complica enormemente la situación descrita, porque ahora Postgres necesita una forma de determinar de alguna manera si la fila pasa el filtro para el índice o no.
PD: En el artículo original, se describe el mecanismo HOT, pero aquí tenemos en mente el mecanismo en el que intervienen solo las tuplas del montón, y el término en sí tiene un significado separado.
Heup only tuple es solo una nueva versión de la línea. Por extraño que parezca, un montón es una tabla, y el montón solo significa que esta línea solo puede ser encontrada por la cadena que conduce desde la versión anterior de la línea llamada raíz.