From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: SQLFunctionCache and generic plans |
Date: | 2023-02-07 15:29:57 |
Message-ID: | 3084885.1675783797@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-02-07 15:46:01 | Re: run pgindent on a regular basis / scripted manner |
Previous Message | Drouvot, Bertrand | 2023-02-07 15:29:07 | Re: Minimal logical decoding on standbys |