Postgresql Performance Tweak - Immutable


In PostgreSQL, every function has one of the possible volatility classifications: volatile, static and immutable. When it is not specified, PostgreSQL assumes that it is a volatile function, which is not always the case.

TL;DR

Volatile: functions with side-effects.

Immutable: pure functional functions.

Stable: smth in between. (wow, such explanation, very clear applause)

Yes, IMHO stable is utterly error-prone and you need to consult to the documentation. Sorry that TL;DR was inadequate :( ..(but.. it is supposed to be inadequate by definition right?? whatever..)


*The moment of discovery of immutable*

*The moment of discovery of immutable*


So, I’d like to draw your attention to immutable functions before this post gets too long. When declaring a function, using the immutable keyword actually implies the following:

  • I solemnly swear that my function does not modify the db.

  • It does not do any database lookups.

  • Given the same arguments, it ALWAYS returns the same output.

BEWARE: As stated in the PostgreSQL documentation, your function should be volatile if you use anything like random(), currval(), timeofday(), current_timestamp(), etc. in your function.

Reader: “So, like.. when shall I use immutable functions? “

Recently, we had to implement a hash function and it was much more appropriate to do the job in PL / pgSQL. So it was all sunshine and lollipops, the hash function came out well etc. But unfortunately it was a tad bit slow. To fix this issue, we just altered the volatility classification of some helper functions. For example, a function that converts characters into ascii values was perfectly suitable to use the immutable keyword!



December 29, 2015