From: | Marko Kreen <markokr(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Which qsort is used |
Date: | 2005-12-13 09:44:38 |
Message-ID: | e51f66da0512130144i47623e1ftc67ecc76560ae543@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/12/05, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
> Qingqing Zhou wrote:
> > Seems we don't link against the port/qsort.c - is there any reason for
> > that? My tests indicates our qsort is much much faster than the libc's.
> Are you willing to say that we should always prefer pgport over glibc's
> qsort()?
I searched the archives and found this:
http://sourceware.org/ml/libc-alpha/2000-03/msg00139.html
Seems glibc guys once tested some implementation of quicksort vs. merge sort
and found out that
"For small sets and smaller data types (arrays of ints and
arrays of doubles) mergesort is definitly faster and behaves better."
If the qsort in Postgres is called usually on wide data - on full rows
not on pointers to rows, then indeed it would be wise to use out own
sort. Especially considering that qsort is not anything OS or machine
-specific, better algorithm beats assembly-optimizations. If we have
a very good good implementation we could use it everywhere.
OTOH, someone should notify glibc devs that their qsort is mediocre,
I don't see much activity on the lists around around that topic.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Mario Weilguni | 2005-12-13 10:03:30 | Deadlock with ShareLocks? |
토토 베이 postgresql | Michael Paesold | 2005-12-13 09:20:21 | Re: Anyone for adding -fwrapv to our standard CFLAGS? |