Chapman Flack <jcflack@acm.org> 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=0dca5d68d7bebf2c1036fd84875533afef6df992
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
