Re: SQLFunctionCache and generic plans - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SQLFunctionCache and generic plans
Date
Msg-id 2691107.1743257329@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQLFunctionCache and generic plans  (Alexander Pyhalov <a.pyhalov@postgrespro.ru>)
Responses Re: SQLFunctionCache and generic plans
List pgsql-hackers
Alexander Pyhalov <a.pyhalov@postgrespro.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Thread-safe nl_langinfo() and localeconv()
Next
From: "David G. Johnston"
Date:
Subject: Re: in BeginCopyTo make materialized view using COPY TO instead of COPY (query).