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
-
Fix performance issue in deadlock-parallel isolation test.
- 837cc73af29c 18.0 landed
-
functions.c: copy trees from source_list before parse analysis etc.
- 0f43083d16f4 18.0 landed
-
Fix oversight in commit 0dca5d68d.
- dbd437e670b8 18.0 landed
-
Change SQL-language functions to use the plan cache.
- 0dca5d68d7be 18.0 landed
-
Reordering DISTINCT keys to match input path's pathkeys
- a8ccf4e93a7e 18.0 cited