| From: | "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Neil Conway" <neilc(at)samurai(dot)com>, "Zdenek Kotala" <Zdenek(dot)Kotala(at)Sun(dot)COM>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PG qsort vs. Solaris |
| Date: | 2006-10-04 07:43:53 |
| Message-ID: | E1539E0ED7043848906A8FF995BDA579016267F7@m0143.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > So basically, glibc's qsort is bad enough that even a
> > 10%-more-comparisons advantage doesn't save it.
> Do those numbers look very different if you have lots of
> columns or if you're sorting on something like an array or a ROW?
Imho, that also is an argument for using our own qsort.
It can be extended to deal with high comparison function cost directly.
Thus I would opt to add a "comparison function cost" arg to qsort_arg
iff
we find scenarios where our qsort performs too bad.
This cost can be used to switch to merge sort for very high cost values.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oleg Bartunov | 2006-10-04 07:49:23 | Re: Tsearch2 and Snowball |
| Previous Message | Dave Page | 2006-10-04 07:42:32 | Re: [HACKERS] cvsweb.cgi missing colors |