On Jan 18, 2004, at 7:28 PM, Tom Lane wrote:
>>> Theory B would be that there's some huge overhead in calling
>>> non-built-in functions on your platform.
>
> I've done some profiling and convinced myself that indeed there's
> pretty
> steep overhead involved in fmgr_info() for a "C"-language function.
> Much of it isn't platform-dependent either --- as best I can tell,
> the lion's share of the time is being eaten in
> expand_dynamic_library_name(). In scenarios where a function is called
> many times per query, we cache the results of fmgr_info() ... but we do
> not do so for operations like ambeginscan that are done just once per
> query.
Wow, thanks for spending the time on this. What about for gettuple?
Do calls to it take advantage of the cache? If not, this likely
explains some of my custom am's performance troubles.
> Every other function language uses shortcuts or caching to reduce the
> cost of fmgr_info() lookup; external C language is the only one that
> hasn't been optimized in this way. I shall see what I can do about
> that.
> ISTM we can have a hash table that maps function OID to function
> address
> using the same sorts of techniques that plpgsql et al use.
If there's anything I can do to help, let me know. I'll be happy to
test any patches you might come up with too.
eric