Re: Which qsort is used
От | Qingqing Zhou |
---|---|
Тема | Re: Which qsort is used |
Дата | |
Msg-id | Pine.LNX.4.58.0512151810270.32684@eon.cs обсуждение исходный текст |
Ответ на | Re: Which qsort is used (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
On Thu, 15 Dec 2005, Greg Stark wrote: > > 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. > [also with reply to Tom] Both ideas look like doable (or at least testable) for me. I agree that the only interesting pot is in tuplesort.c. For the 2nd idea, for smaller range, we may consider radix sort, which is definitely faster - but this may need some work that enable query optimizer know the *exact* data range. Regards, Qingqing
В списке pgsql-hackers по дате отправления: