From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, Luke Lonergan <llonergan(at)greenplum(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 22:46:08 |
Message-ID: | 87fyouc72n.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > Based on this it seems like we should expose the option to choose the BSD
> > > qsort routine at configure time.
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. This
might perform faster for a few reasons. The comparator is much more likely to
be eligible for inlining for one.
It also opens the door to using different sort algorithms for different
applications. There may be some cases where the input is never sorted and the
sample size is small so qsort is a good choice, and others where the inputs
can be large and using a better algorithm with worse overhead like mergesort
might make more sense.
Unfortunately there isn't just a single qsort call though. I count 6
comparators in the source tree I have. So perhaps this is a non-starter.
Having 6 qsort implementations around sounds pretty sketchy.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Zoltan Boszormenyi | 2005-12-15 22:59:19 | Re: Interesting speed anomaly |
Previous Message | Jim C. Nasby | 2005-12-15 22:21:20 | Re: postgres version control? |