Re: [GENERAL] Re : Solaris Performance - Profiling (Solved) - Mailing list pgsql-hackers

From Doug McNaught
Subject Re: [GENERAL] Re : Solaris Performance - Profiling (Solved)
Date
Msg-id m3d6xg69k0.fsf@varsoon.wireboard.com
Whole thread Raw
In response to Re: [GENERAL] Re : Solaris Performance - Profiling (Solved)  (Justin Clift <justin@postgresql.org>)
Responses Re: [GENERAL] Re : Solaris Performance - Profiling (Solved)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
mlw <markw@mohawksoft.com> writes:

> > Because qsort() is *supposed* to be optimized by the vendor for their
> > platform, perhaps even written in assembler.  It makes sense to trust
> > the vendor except when their implementation is provably pessimized.
> 
> Perhaps *supposed* to be optimized, but, in reality, are they? Is it a
> realistic expectation?

I think most vendors do a pretty good job.  Don't forget, optimizing a
routine like that depends a lot on the cache size and behavior of the
CPU and other architecture-dependent stuff.  

> qsort() is a great sort for very random data, when data is mostly in the
> correct order, it is very bad. Perhaps replacing it with an alternate sort
> would improve performance in general.

Actually, the C standard says nothing about what algorithm should be
used for qsort(); it's simply supposed to be a fast in-memory sort.
The qsort() name is just a historical artifact.

-Doug
-- 
Doug McNaught       Wireboard Industries      http://www.wireboard.com/
     Custom software development, systems and network consulting.     Java PostgreSQL Enhydra Python Zope Perl Apache
LinuxBSD...
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Suggestions please: names for function cachability attributes
Next
From: mlw
Date:
Subject: Re: Suggestions please: names for function cachability