Re: Selecting Function Volatility Category

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Dinesh Somani <dinesh(at)opsveda(dot)com>, pgsql-novice(at)lists(dot)postgresql(dot)org
Subject: Re: Selecting Function Volatility Category
Date: 2019-09-23 10:39:28
Message-ID: 6a7d1dd21499a2817b2cd10e18e3b02329d01ce2.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

Dinesh Somani wrote:
> I have an id lookup function that translates string names into
> numeric id. The names are pretty stable over the life of the system
> but still can mutate once in a while (like, once a month) when
> someone updates configurations. I can use it like...
>
> WHERE ... a.attribute_id = f('SALES', 'MATERIAL_NUMBER') ...
>
> Currently I am classfying the function as STABLE. I would prefer to
> use category IMMUTABLE as that might be more performant. (
> https://www.postgresql.org/docs/current/xfunc-volatility.html) How
> does one tackle the occasional case when the cached values of the
> function no longer apply? Is there some way to trigger cache
> invalidation?
>
> I had thought of deleting and recreating the function. But that
> leaves a tiny gap during which the function becomes non-existent
> (leading to a hit on my SLAs), plus may also cause plan invalidations
> all over the application.

As long as you don't use the function in an index, it is not so
dangerous to cheat by marking the function IMMUTABLE.

The other concern may be cached plans that use the function.
One simple was to invalidate them would be to run an ALTER FUNCTION:

ALTER FUNCTION f IMMUTABLE;

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com

In response to

Browse pgsql-novice by date

  From Date Subject
Next Message Potvin 2019-09-26 16:12:14 Security question
Previous Message Tom Lane 2019-09-21 14:54:00 Re: Getting to grips with Recursive CTEs.