| From: | mlw <markw(at)mohawksoft(dot)com> | 
|---|---|
| To: | Doug McNaught <doug(at)wireboard(dot)com> | 
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Justin Clift <justin(at)postgresql(dot)org>, Mark kirkwood <markir(at)slingshot(dot)co(dot)nz>, PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: [GENERAL] Re : Solaris Performance - Profiling (Solved) | 
| Date: | 2002-04-03 15:57:08 | 
| Message-ID: | 3CAB2654.D66CC887@mohawksoft.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general pgsql-hackers | 
Doug McNaught wrote:
> 
> mlw <markw(at)mohawksoft(dot)com> writes:
> 
> > I noticed poor performance on Solaris, does one see this problem
> > when compiling PostgreSQL with gcc on solaris?
> 
> Since it's libc that's the culprit, I would imagine so.
Thanks, that explains what I have seen.
> 
> > As a suggestion, why not find the *best* version of qsort available,
> > anywhere, and always use that version on all platforms?
> 
> 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?
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steve Lane | 2002-04-03 16:10:08 | Postgres/PHP, Apache child processes dying | 
| Previous Message | Doug McNaught | 2002-04-03 15:49:28 | Re: [GENERAL] Re : Solaris Performance - Profiling (Solved) | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | mlw | 2002-04-03 16:11:28 | Re: Suggestions please: names for function cachability | 
| Previous Message | Tom Lane | 2002-04-03 15:52:41 | Re: command.c breakup |