I wrote:
>> It occurs to me that there's no good reason to do this lookup more
>> than once per column --- all the tuples in a relation should have
>> the same set of column types, no? So if we could do these lookups
>> once at the start of an output pass, and cache the results for use
>> in individual printtup calls, we could drive that 10% down to zero
>> at essentially no penalty.
>> [ snip ]
>> ... as long as we are
>> precalculating stuff, it would also be worthwhile to precalculate the
>> info that fmgr.c needs in order to invoke the routine. For builtin
>> functions it seems to me that we ought to be able to reduce the
>> per-tuple call effort to a straight jump through a function pointer,
>> which would save almost another 10% of SELECT's runtime.
I have implemented and checked in both of these ideas, and gotten the
expected savings in runtime of large SELECTs.
It turns out that someone was way ahead of me concerning optimizing
calls through fmgr.c --- it already is possible to precalculate the
target function address (fmgr_info) and then do a direct jump through
the function pointer (fmgr_faddr). But printtup.c was using the
combined-lookup-and-call routine fmgr() for each tuple, rather than
precalculating the function info and re-using it. This was probably
because it didn't have any good place to cache the info --- but it
does now.
There are a number of other places that look like they might profit from
the same kind of optimization --- in particular, GROUP BY and UNIQUE
(SELECT DISTINCT) processing call fmgr() for each tuple. Also, index
processing uses fmgr() rather than precalculated calls. I haven't done
anything about this but perhaps someone else would like to.
regards, tom lane
