Re: scalar plpgsql functions and their stability flags

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Victor Dobrovolsky <booby(dot)stager(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: scalar plpgsql functions and their stability flags
Date: 2024-05-26 14:27:14
Message-ID: 2721.1716733634@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Victor Dobrovolsky <booby(dot)stager(at)gmail(dot)com> writes:
> It is clear that for immutable/stable functions with constant parameters,
> query planner could/should calculate value in a parse time and use it
> directly in query, or at least once per query.

Immutable, yes, stable, no.

Awhile back there was a draft patch to cache outputs of stable functions
after running them once in a query, but I don't think anyone's still
working on that. IIRC we were having a hard time convincing ourselves
that the extra bookkeeping would pay for itself.

> But it is unclear for me what exactly should/can happens when parameters
> are bounded not to constant values but to query fields.
> In such a case there could be some caching mechanics involved for
> parameters combinations and result values.
> Like building a hash table for that or something similar.

No such mechanism exists. Again, there would be a lot of tradeoffs
involved and it's difficult to say if it'd be a win.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2024-05-26 15:00:26 Re: Long running query causing XID limit breach
Previous Message Victor Dobrovolsky 2024-05-26 13:20:10 scalar plpgsql functions and their stability flags