Horton

Re: SQLFunctionCache and generic plans

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Pyhalov <a.pyhalov@postgrespro.ru>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Alexander Korotkov <aekorotkov@gmail.com>, pgsql-hackers@lists.postgresql.org, Ronan Dunklau <ronan.dunklau@aiven.io>
Date: 2025-03-29T14:08:49Z
Lists: 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

Commits

  1. Fix performance issue in deadlock-parallel isolation test.

  2. functions.c: copy trees from source_list before parse analysis etc.

  3. Fix oversight in commit 0dca5d68d.

  4. Change SQL-language functions to use the plan cache.

  5. Reordering DISTINCT keys to match input path's pathkeys