Dichiarare la volatilità delle funzioni IMMUTABILE può danneggiare le prestazioni?

Le funzioni di Postgres sono dichiarate con classificazione di volatilità VOLATILE, STABLEoIMMUTABLE . Il progetto è noto per essere molto severo con queste etichette per le funzioni integrate. E con una buona ragione. Esempio di spicco: gli indici di espressione consentono solo IMMUTABLEfunzioni e queste devono essere veramente immutabili per evitare risultati errati.

Le funzioni definite dall'utente sono ancora libere di essere dichiarate quando il proprietario sceglie. Il manuale consiglia:

Per i migliori risultati di ottimizzazione, è necessario etichettare le funzioni con la categoria di volatilità più rigorosa valida per esse.

... e aggiunge un ampio elenco di cose che possono andare storte con un'etichetta di volatilità errata.

Tuttavia, ci sono casi in cui falsificare l'immutabilità ha senso. Soprattutto quando sai che la funzione è, infatti, immutabile nel tuo ambito. Esempio:

• PostgreSQL supporta regole di confronto "insensibili all'accento"?

Tutte le possibili implicazioni sull'integrità dei dati a parte , qual è l'effetto sulle prestazioni? Si potrebbe supporre che la dichiarazione di una funzione IMMUTABLEpossa essere vantaggiosa solo per le prestazioni . È così?

La dichiarazione di volatilità delle funzioni può IMMUTABLE danneggiare le prestazioni?

Supponiamo che l'attuale Postgres 10 lo restringa, ma tutte le versioni recenti sono interessanti.

Sì, può danneggiare le prestazioni.

Le funzioni SQL semplici possono essere "incorporate" nella query chiamante. Citando il Wiki di Postgres :

Le funzioni SQL (ad es. LANGUAGE SQL) Avranno, in determinate condizioni, i loro corpi funzione incorporati nella query chiamante anziché essere richiamati direttamente. Ciò può comportare vantaggi sostanziali in termini di prestazioni poiché il corpo della funzione viene esposto al pianificatore della query chiamante, che può applicare ottimizzazioni come la piegatura costante, il pushdown di qualità e così via.

Enorme enfasi sulla mia.

Per imporre la correttezza, ci sono una serie di condizioni preliminari. Uno di questi :

se la funzione è dichiarata IMMUTABLE, l'espressione non deve invocare alcuna funzione o operatore non immutabile

Significato, le funzioni SQL che utilizzano qualsiasi funzione non immutabile ma che sono ancora dichiarate IMMTUTABLEsono escluse da questa ottimizzazione. Innescato da queste risposte correlate su SO, ho eseguito test approfonditi:

• Come aggregare i dati di più anni su MM-DD, ignorando l'anno
• Come si fa a uscire con la matematica che ignora l'anno?

Fondamentalmente confrontando queste due varianti di una semplice funzione SQL (mappando le date a un integer, ignorando l'anno che non ha importanza per lo scopo):

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 funzione Postgres to_char()è solo STABLE, non IMMUTABLE(tutte le sue istanze sovraccaricate - per ragioni che esulano dallo scopo di questa risposta ). Quindi il secondo è falso IMMUTABLEe risulta essere 5 volte più lento in un semplice test:

db <> violino qui

Questo esempio specifico può essere sostituito con l'equivalente:

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

Sarebbe sembrare più costoso con due chiamate di funzione e altri calcoli. Ma l' IMMUTABLEetichetta è vero (più, la funzione utilizzata è più veloce e costringere texta integerè più costoso, troppo).

2 volte più veloce della variante più veloce sopra (10 volte più veloce del più lento). Il punto è: usa le IMMUTABLEfunzioni ove possibile , quindi non devi "imbrogliare" per cominciare.