From: Tom Lane <tgl@sss.pgh.pa.us>
To: Victor Dobrovolsky <booby.stager@gmail.com>
cc: pgsql-general@lists.postgresql.org
Subject: Re: scalar plpgsql functions and their stability flags
In-reply-to: <CAJFsatN_5EkCuk8GqUG_1iOD0ON6x4BTeMWU08Jierr5m+GD7Q@mail.gmail.com>
References: <CAJFsatN_5EkCuk8GqUG_1iOD0ON6x4BTeMWU08Jierr5m+GD7Q@mail.gmail.com>
Comments: In-reply-to Victor Dobrovolsky <booby.stager@gmail.com>
	message dated "Sun, 26 May 2024 16:20:10 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2720.1716733634.1@sss.pgh.pa.us>
Date: Sun, 26 May 2024 10:27:14 -0400
Message-ID: <2721.1716733634@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2721.1716733634%40sss.pgh.pa.us>
Precedence: bulk

Victor Dobrovolsky <booby.stager@gmail.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