| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, Luke Lonergan <llonergan(at)greenplum(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Which qsort is used |
| Date: | 2005-12-15 23:06:21 |
| Message-ID: | 17991.1134687981@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> I have a related question. qsort is only used in the postgres source in a few
> places. If postgres used an internal implementation instead of the library
> source it could have implementations that don't use function pointers.
There are calls to qsort in upwards of 40 different source files; many
of those files contain multiple comparator functions. Doesn't look like
"a few" to me. But I'll grant that the vast majority are not
performance critical. One could imagine putting a custom implementation
into only tuplesort.c, say, where you could certainly get rid of one
level of function call (qsort_comparetup) by providing a saner API that
passes a state pointer as well as a function pointer to the qsort code.
Whether that would be worth the trouble is a question for experiment ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Qingqing Zhou | 2005-12-15 23:15:51 | Re: Which qsort is used |
| Previous Message | Zoltan Boszormenyi | 2005-12-15 22:59:19 | Re: Interesting speed anomaly |