Re: [HACKERS] Another speedup idea (two, even)

> 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.
> 

Certainly sounds like it would be a big win.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026