La parola chiave IMMUTABLE è mai aggiunto automaticamente da pgAdmin o Postgres. Chiunque abbia creato o sostituito la funzione lo ha fatto.
La corretta volatilità poiché la funzione data è VOLATILE (anche l'impostazione predefinita), non STABLE - o non avrebbe senso usare clock_timestamp() che è VOLATILE in contrasto con now() o CURRENT_TIMESTAMP che sono STABLE :quelli restituiscono lo stesso timestamp all'interno della stessa transazione. Il manuale:
clock_timestamp() restituisce l'ora corrente effettiva, e quindi il suo valore cambia anche all'interno di un singolo comando SQL.
Il manuale avverte che la funzione volatilità STABLE ...
non è appropriato per AFTER trigger che desiderano interrogare le righe modificate dal comando corrente.
.. perché la valutazione ripetuta della funzione trigger può restituire diversi risultati per la stessa riga. Quindi, non STABLE .
Chiedi:
Hai un'idea del motivo per cui la funzione è tornata correttamente cinque volte prima di rimanere sul quinto valore quando è impostato come IMMUTABLE ?
Il Wiki di Postgres:
Con 9.2, il pianificatore utilizzerà piani specifici relativi ai parametri inviati (la query verrà pianificata all'esecuzione), salvo che la query venga eseguita più volte e il pianificatore decide che il piano generico non è molto più costoso dei piani specifici.
Enfasi in grassetto mio. Non sembra avere senso per un IMMUTABLE funzione senza parametri di input. Ma la falsa etichetta è sovrascritta da VOLATILE funzione nel corpo (vuota funzionamento in linea ):un piano di query diverso può ancora avere senso. Correlati:
- Prestazioni della stored procedure PostgreSQL
A parte
trunc() è leggermente più veloce di floor() e fa lo stesso qui, poiché i numeri positivi sono garantiti:
SELECT (trunc(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int
