database - tag - ¿Cómo influyen las palabras clave INMUTABLE, ESTABLE y VOLÁTIL en el comportamiento de la función?
title en seo (1)
La palabra clave IMMUTABLE nunca se agrega automáticamente por pgAdmin o Postgres. Quien alguna vez creó o reemplazó la función hizo eso.
La configuración de volatilidad de función correcta (leer el manual) para la función dada es VOLATILE , no STABLE , o no tendría sentido utilizar clock_timestamp() que es VOLATILE en oposición a now() o CURRENT_TIMESTAMP , que se definen STABLE : aquellos devuelve la misma marca de tiempo dentro de la misma transacción, según la documentación :
clock_timestamp()devuelve la hora actual real, y por lo tanto su valor cambia incluso dentro de un solo comando SQL.
El manual advierte que la volatilidad de la función STABLE ...
es inapropiado para los desencadenadores
AFTERque desean consultar las filas modificadas por el comando actual.
.. porque la evaluación repetida de la función de disparo para la misma fila puede devolver resultados diferentes . Entonces, no STABLE . No creo que la advertencia sea siquiera necesaria allí, ya que es bastante obvio.
Y preguntas:
¿Tiene una idea de por qué la función volvió correctamente cinco veces antes de quedarse en el quinto valor cuando se establece como
IMMUTABLE?
Citando la Wiki de Postgres :
Con 9.2, el planificador utilizará planes específicos con respecto a los parámetros enviados (la consulta se planificará en la ejecución), excepto si la consulta se ejecuta varias veces y el planificador decide que el plan genérico no es mucho más costoso que los planes específicos. .
Negrita énfasis mío. No parece tener sentido para una función IMMUTABLE (tampoco daña), pero tal vez el uso de una función VOLATILE dentro aún desencadena una redefinición inicial. (El último bit es solo mi especulación).
Más explicación aquí:
Aparte
trunc() es ligeramente más rápido que floor() y hace lo mismo aquí, ya que los números positivos están garantizados:
SELECT (trunc(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int
Escribimos una función get_timestamp() definida como
CREATE OR REPLACE FUNCTION get_timestamp()
RETURNS integer AS
$$
SELECT (FLOOR(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int;
$$
LANGUAGE SQL;
Esto se utilizó en INSERT y UPDATE para ingresar o editar un valor en un campo creado y modificado en el registro de la base de datos. Sin embargo, al agregar o actualizar registros de forma consecutiva, encontramos que devolvía el mismo valor.
Al inspeccionar la función en pgAdmin III, notamos que al ejecutar el SQL para construir la función, la palabra clave IMMUTABLE se había inyectado después de la instrucción LANGUAGE SQL. La documentación indica que el valor predeterminado es VOLATILE (si no aparece ninguno de estos, VOLATILE es la suposición predeterminada), por lo que no estoy seguro de por qué se inyectó INMUTABLE; sin embargo, al cambiar esto a STABLE se solucionó el problema de los valores repetidos.
NOTA: Como se establece en la respuesta aceptada, IMG PUNTE nunca se agrega a una función por pgAdmin o Postgres y debe haber sido agregado durante el desarrollo.
Supongo que lo que sucedía era que esta función se estaba evaluando y el resultado se almacenaba en la memoria caché para su optimización, ya que estaba marcado INMUTABLE indicando al motor de Postgres que el valor de retorno no debería cambiar dada la misma lista de parámetros (vacía). Sin embargo, cuando no se usa dentro de un disparador, cuando se utiliza directamente en la instrucción INSERT, la función devolverá un valor distinto CINCO veces antes de devolver el mismo valor a partir de ese momento. ¿Esto se debe a algún algoritmo de optimización que dice algo así como "Si se usa una función IMMUTABLE más de 5 veces en una sesión, guarde el resultado en caché para futuras llamadas"?
Cualquier aclaración sobre cómo deberían usarse estas palabras clave en las funciones de Postgres sería apreciada. Es ESTABLE la opción correcta para nosotros dado que usamos esta función en desencadenantes, o hay algo más que considerar, por ejemplo, los documentos dicen:
(No es apropiado para los activadores DESPUÉS que desean consultar las filas modificadas por el comando actual).
Pero no estoy del todo claro por qué.