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: | Raw Message | Whole Thread | 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 |