sql >> Base de Datos >  >> RDS >> PostgreSQL

Datos redundantes en sentencias de actualización

Debido a PostgreSQL MVCC, una UPDATE es efectivamente muy parecido a un DELETE más un INSERT . Con la notable excepción de los valores tostados, consulte:

  • ¿Postgres reescribe toda la fila en la actualización?

(Y diferencias menores para tuplas de solo montón - DELETE + INSERT inicia una nueva cadena CALIENTE, pero eso no tiene nada que ver con el caso en cuestión).

Para ser precisos, la fila "eliminada" es simplemente invisible para cualquier transacción que comience después de que se haya confirmado la eliminación y se aspire más tarde. Por lo tanto, en el lado de la base de datos, incluida la manipulación de índices, en efecto no hay diferencia. entre las dos declaraciones. (Se aplican excepciones, siga leyendo). Aumenta un poco el tráfico de red (dependiendo de sus datos) y necesita un poco de análisis.

Estudié las actualizaciones HOT un poco más después de la entrada de @araqnid y realicé algunas pruebas. Las actualizaciones en columnas que en realidad no cambian el valor no hacen ninguna diferencia en lo que respecta a las actualizaciones HOT. Mi respuesta se mantiene. Ver detalles a continuación.

Esto también se aplica a los atributos tostados, ya que tampoco se tocan a menos que los valores cambien realmente. .

Sin embargo , si usa activadores por columna (presentado en la página 9.0), ¡esto puede tener efectos secundarios no deseados!

Cito el manual sobre disparadores:

... un comando como UPDATE ... SET x = x ... disparará un activador en la columna x , aunque el valor de la columna no cambió .

Énfasis en negrita mío.

Las capas de abstracción son por conveniencia. Son útiles para desarrolladores analfabetos de SQL o si la aplicación necesita ser portátil entre diferentes RDBMS. En el lado negativo, pueden sacrificar el rendimiento e introducir puntos adicionales de falla. Los evito siempre que puedo.

Actualizaciones HOT (solo tupla de almacenamiento dinámico)

Las tuplas de almacenamiento dinámico se introdujeron con Postgres 8.3, con mejoras importantes en 8.3.4 y 8.4.9.
Las notas de la versión para Postgres 8.3:

UPDATE s y DELETE s dejan atrás las tuplas muertas, al igual que INSERT fallido s.Anteriormente solo VACUUM podría recuperar el espacio ocupado por las tuplas muertas. El espacio de tupla muerta WithHOT se puede recuperar automáticamente en el momento de INSERT o UPDATE si no se realizan cambios en las columnas indexadas . Esto permite un rendimiento más consistente. Además, HOT evita agregar entradas de índice duplicadas.

Énfasis mío. Y "sin cambios" incluye casos en los que las columnas se actualizan con el mismo valor que ya tienen. Yo realmente probé , ya que no estaba seguro.

En última instancia, el extenso README.HOT en el código fuente lo confirma.

Las columnas tostadas tampoco se interponen en el camino de las actualizaciones CALIENTES. La tupla actualizada en CALIENTE simplemente se vincula a la misma tupla sin cambios en la bifurcación del brindis de la relación. Las actualizaciones HOT incluso funcionan con valores tostados en la lista de objetivos (realmente cambiados o no). Si se cambian los valores tostados, implica escrituras en la bifurcación de relación tostada, obviamente. También probé todo eso.

No confíe en mi palabra, compruébelo usted mismo. Postgres proporciona un par de funciones para comprobar las estadísticas. Ejecute su UPDATE con y sin todas las columnas y verifique si hay alguna diferencia.

-- Number of rows HOT-updated in table:
SELECT pg_stat_get_tuples_hot_updated('table_name'::regclass::oid)

-- Number of rows HOT-updated in table, in the current transaction:
SELECT pg_stat_get_xact_tuples_hot_updated('table_name'::regclass::oid)

O use pgAdmin. Seleccione su tabla e inspeccione la pestaña "Estadísticas" en la ventana principal.

Tenga en cuenta que las actualizaciones HOT solo son posibles cuando hay espacio para la nueva versión de tupla en la misma página de la bifurcación de relación principal. Una forma sencilla de forzar esa condición es probar con una pequeña tabla que contiene solo unas pocas filas. El tamaño de la página suele ser de 8k, por lo que debe haber espacio libre en la página.