¿Declarar la volatilidad de la función INMUTABLE puede dañar el rendimiento?

Las funciones de Postgres se declaran con clasificación de volatilidad VOLATILE, STABLEoIMMUTABLE . Se sabe que el proyecto es muy estricto con estas etiquetas para las funciones integradas. Y con buen motivo. Ejemplo destacado: los índices de expresión solo permiten IMMUTABLEfunciones y esas deben ser verdaderamente inmutables para evitar resultados incorrectos.

Las funciones definidas por el usuario aún pueden declararse libremente según lo elija el propietario. El manual aconseja:

Para obtener los mejores resultados de optimización, debe etiquetar sus funciones con la categoría de volatilidad más estricta que sea válida para ellas.

... y agrega una extensa lista de cosas que pueden salir mal con una etiqueta de volatilidad incorrecta.

Aún así, hay casos en los que tiene sentido falsificar la inmutabilidad. Principalmente cuando sabe que la función es, de hecho, inmutable dentro de su alcance. Ejemplo:

• ¿PostgreSQL admite colaciones "insensibles al acento"?

Dejando a un lado todas las posibles implicaciones en la integridad de los datos , ¿cuál es el efecto en el rendimiento? Se podría suponer que declarar una función IMMUTABLEsolo puede ser beneficiosa para el rendimiento . ¿Es eso así?

¿La declaración de volatilidad de la función puede IMMUTABLE dañar el rendimiento?

Supongamos que Postgres 10 actual lo reduce, pero todas las versiones recientes son de interés.

Sí, puede dañar el rendimiento.

Las funciones SQL simples se pueden "en línea" en la consulta de llamada. Citando el Wiki de Postgres :

Las funciones SQL (es decir LANGUAGE SQL), bajo ciertas condiciones, tendrán sus cuerpos de función integrados en la consulta de llamada en lugar de ser invocados directamente. Esto puede tener ventajas sustanciales de rendimiento ya que el cuerpo de la función queda expuesto al planificador de la consulta de llamada, que puede aplicar optimizaciones tales como el plegado constante, el pushdown de calidad, etc.

El énfasis audaz es mío.

Para hacer cumplir la corrección, hay una serie de condiciones previas. Uno de ellos :

si se declara la función IMMUTABLE, la expresión no debe invocar ninguna función u operador no inmutable

Es decir, las funciones SQL que utilizan funciones no inmutables pero que aún se declaran IMMTUTABLEestán excluidas de esta optimización. Activado por estas respuestas relacionadas en SO, he estado realizando pruebas exhaustivas:

• Cómo agregar datos de varios años en MM-DD, ignorando el año
• ¿Cómo se fecha matemática que ignora el año?

Básicamente, comparando estas dos variantes de una función SQL simple (asignando fechas a una integer, ignorando el año que no importa para ese propósito):

CREATE FUNCTION f_mmdd_tc_s(date) RETURNS int LANGUAGE sql STABLE    AS
$$SELECT to_char($1, 'MMDD')::int$$;

CREATE FUNCTION f_mmdd_tc_i(date) RETURNS int LANGUAGE sql IMMUTABLE AS
$$SELECT to_char($1, 'MMDD')::int$$;  -- cannot be inlined!

La función Postgres to_char()es única STABLE, no IMMUTABLE(todas las instancias sobrecargadas de la misma, por razones más allá del alcance de esta respuesta ). Entonces, el segundo es falso IMMUTABLEy resulta ser 5 veces más lento en una prueba simple:

db <> violín aquí

Este ejemplo específico se puede reemplazar con el equivalente:

CREATE FUNCTION f_mmdd(date) RETURNS int LANGUAGE sql IMMUTABLE AS
$$SELECT (EXTRACT(month FROM $1) * 100 + EXTRACT(day FROM $1))::int$$;

Sería parecer más caro con dos llamadas a funciones y más cálculos. Sin embargo, la IMMUTABLEetiqueta es verdadera (además, la función de uso es más rápido y coaccionar texta integeres más caro, también).

2 veces más rápido que la variante más rápida anterior (10 veces más rápido que el más lento). El punto es: usar IMMUTABLEfunciones cuando sea posible , para no tener que "hacer trampa".