From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Another speedup idea (two, even) |
Date: | 1999-07-07 00:52:23 |
Message-ID: | 199907070052.UAA27823@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-07-07 01:25:12 | Re: [HACKERS] new heap manager mmalloc |
Previous Message | Bruce Momjian | 1999-07-07 00:43:27 | Re: [HACKERS] Postgres Speed or lack thereof |