| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | 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-03 21:03:59 |
| Message-ID: | 87ejtp6ri8.fsf@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> So basically, glibc's qsort is bad enough that even a
> 10%-more-comparisons advantage doesn't save it.
Actually what I was more concerned about was things like on data structures
with complex comparison routines. Things like sorting on arrays or ROWs.
For that matter it seems to me that sorting on a single column is a pretty
unrealistic scenario too. Most of the time I find queries have long lists of
columns in the ORDER BY clause.
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?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2006-10-03 21:06:09 | Re: Pie-in-sky dreaming about reworking tuple layout entirely |
| Previous Message | Tom Lane | 2006-10-03 21:02:25 | Re: PG qsort vs. Solaris |