public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Chapman Flack <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: FmgrInfo allocation patterns (and PL handling as staged programming)
Date: Sun, 06 Apr 2025 13:33:47 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
Chapman Flack <[email protected]> writes:
> To wit, given a query like
> SELECT hello(n), hello(x)
> FROM (VALUES
> (1::int4, 1.0::float4),
> (2, 2.0 ),
> (3, 3.0 )) AS t(n,x);
> the core code allocates one FmgrInfo for each of the two uses.
Yeah, there's no attempt to merge FmgrInfos across call sites
within a query. It's typical to use fn_extra to point to dynamic
state for a call, so that any such merging could break things.
> I wonder, though, if there might be code in the wild, or even in corners
> of the core I haven't looked in, where FmgrInfo structs aren't being used
> that way, and could get reused for successive calls of one routine but
> with, say, different nargs or argument types. That would seem odd but
> I don't see that the documentation ever came right out and said not to.
The only case I'm aware of that might require some thought is that the
relcache caches FmgrInfo structs for the opclass support functions for
each column of an index. That seems like it's close enough to being
just as specialized as a query callsite, but maybe not?
A downside of relying entirely on fn_extra is that you don't get to
amortize the specialization work across queries, even though it's
probably pretty repetitive. You might be interested in this recent
commit:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0dca5d68d7bebf2c1036fd84875533afe...
which formalizes some caching rules that plpgsql has used for
a long time, and extends the rules to support SQL-language
functions (which need to specialize on output rowtype as well
as what plpgsql has traditionally considered). Maybe you'd be
interested in using funccache.
regards, tom lane
view thread (4+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: FmgrInfo allocation patterns (and PL handling as staged programming)
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox