From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> |
Subject: | Re: SQLFunctionCache and generic plans |
Date: | 2025-03-29 14:08:49 |
Message-ID: | 2691107.1743257329@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru> writes:
> After writing some comments, looking at it once again, I've found that
> one assumption is wrong - function can be discarded from cache during
> its execution.
Yeah. You really need a use-count on the shared cache object.
I've been working on pulling out plpgsql's code that manages its
function cache into a new module that can be shared with functions.c.
That code is quite battle-tested and I don't see a good argument
for reinventing the logic. It's not fit to share yet, but I hope
to have something in a day or so.
> Also one interesting note is as we don't use raw_parse_tree, it seems we
> don't need plansource->parserSetup and plansource->parserSetupArg. It
> seems we can avoid caching complete parse info.
Well, you do need those when dealing with an old-style function (raw
parse trees).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2025-03-29 14:40:55 | Re: in BeginCopyTo make materialized view using COPY TO instead of COPY (query). |
Previous Message | Andres Freund | 2025-03-29 14:08:06 | Re: Thread-safe nl_langinfo() and localeconv() |