From: | "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: qsort again (was Re: Strange Create Index |
Date: | 2006-02-16 11:35:22 |
Message-ID: | 20060216113522.GA3461@uio.no |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Wed, Feb 15, 2006 at 11:30:54PM -0500, Ron wrote:
> Even better (and more easily scaled as the number of GPR's in the CPU
> changes) is to use
> the set {L; L+1; L+2; t>>1; R-2; R-1; R}
> This means that instead of 7 random memory accesses, we have 3; two
> of which result in a
> burst access for three elements each.
Isn't that improvement going to disappear competely if you choose a bad
pivot?
> SIDE NOTE: IIRC glibc's qsort is actually merge sort. Merge sort
> performance is insensitive to all inputs, and there are way to
> optimize it as well.
glibc-2.3.5/stdlib/qsort.c:
/* Order size using quicksort. This implementation incorporates
four optimizations discussed in Sedgewick:
I can't see any references to merge sort in there at all.
/* Steinar */
--
Homepage: http://www.sesse.net/
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Weimer | 2006-02-16 12:10:48 | Re: qsort again |
Previous Message | Martijn van Oosterhout | 2006-02-16 11:30:43 | Re: Generating config stuff from single source |
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Weimer | 2006-02-16 12:10:48 | Re: qsort again |
Previous Message | Gary Doades | 2006-02-16 11:06:32 | Re: [HACKERS] qsort again (was Re: Strange Create Index |