Re: [HACKERS] Another speedup idea (two, even)
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Another speedup idea (two, even) |
Дата | |
Msg-id | 199907070052.UAA27823@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Another speedup idea (two, even) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Added to TODO: * use fmgr_info()/fmgr_faddr() instead of fmgr() calls in high-traffic places, like GROUP BY, UNIQUE, index processing, etc. > 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 > > -- 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
В списке pgsql-hackers по дате отправления: