Re: SQLFunctionCache and generic plans

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ronan Dunklau <ronan.dunklau@aiven.io>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2023-02-07T15:29:57Z
Lists: pgsql-hackers
Ronan Dunklau <ronan.dunklau@aiven.io> writes:
> The following comment can be found in functions.c, about the SQLFunctionCache:

>  * Note that currently this has only the lifespan of the calling query.
>  * Someday we should rewrite this code to use plancache.c to save parse/plan
>  * results for longer than that.

> I would be interested in working on this, primarily to avoid this problem of 
> having generic query plans for SQL functions but maybe having a longer lived 
> cache as well would be nice to have.
> Is there any reason not too, or pitfalls we would like to avoid ?

AFAIR it's just lack of round tuits.  There would probably be some
semantic side-effects, though if you pay attention you could likely
make things better while you are at it.  The existing behavior of
parsing and planning all the statements at once is not very desirable
--- for instance, it doesn't work to do
	CREATE TABLE foo AS ...;
	SELECT * FROM foo;
I think if we're going to nuke this code and start over, we should
try to make that sort of case work.

			regards, tom lane



Commits

  1. Fix performance issue in deadlock-parallel isolation test.

  2. functions.c: copy trees from source_list before parse analysis etc.

  3. Fix oversight in commit 0dca5d68d.

  4. Change SQL-language functions to use the plan cache.

  5. Reordering DISTINCT keys to match input path's pathkeys