Re: SQLFunctionCache and generic plans

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

In response to

Browse pgsql-hackers by date

  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