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

From mlw
Subject Re: [GENERAL] Re : Solaris Performance - Profiling (Solved)
Date
Msg-id 3CAB2CB2.1745AC2F@mohawksoft.com
Whole thread Raw
In response to Re: [GENERAL] Re : Solaris Performance - Profiling (Solved)  (Justin Clift <justin@postgresql.org>)
List pgsql-hackers
Doug McNaught wrote:
> 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.

Perhaps so, but maybe that is the issue with Solaris, it actually may use qsort
algorithm.

I am not too sure how one would optimize the qsort() API on a platform basis.
The sorting algorithm uses a callback function, this precludes any meaningful
optimization. Yea, you can play with memory page sizes, and so on, but you
still have to do a function call for some multiple of the number of elements in
the array.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Re : Solaris Performance - Profiling (Solved)
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Re : Solaris Performance - Profiling (Solved)