Re: qsort again (was Re: Strange Create Index

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/

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-performance by date

  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