On Wed, Apr 03, 2002 at 11:35:30AM -0500, Tom Lane wrote:
> Andrew Sullivan <[EMAIL PROTECTED]> writes:
>
> > ... so we can be fairly certain the problem is in the
> > 32 bit library. Maybe the 64 bit one is better?
>
> Good point. Please check it out and let us know.
Sorry this has taken me
mlw <[EMAIL PROTECTED]> writes:
> quicksort is a pretty poor algorithm if your data is in some kind of order
> already.
Only if you fail to take standard precautions against making a bad
choice of pivot element; every discussion I've ever seen of quicksort
explains ways to avoid that pitfall. So
Tom Lane wrote:
>
> Doug McNaught <[EMAIL PROTECTED]> writes:
> > 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.
>
> In practice I believe qsort usual
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Wed, Apr 03, 2002 at 10:23:41AM -0500, Tom Lane wrote:
>> But I can't see any reasonable way for configure to decide automatically
>> whether we should replace the system qsort. I think we'd have to put
>> a USE_PRIVATE_QSORT symbol definition into
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
>> corr
Doug McNaught <[EMAIL PROTECTED]> writes:
> 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.
In practice I believe qsort usually is a quicksort; it's just to
mlw <[EMAIL PROTECTED]> 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,
Doug McNaught wrote:
>
> mlw <[EMAIL PROTECTED]> 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 sug
mlw <[EMAIL PROTECTED]> 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.
> As a suggestion, why not find the *best* version of qsort available,
> anywhere, and alwa
On Wed, Apr 03, 2002 at 10:23:41AM -0500, Tom Lane wrote:
> Justin Clift <[EMAIL PROTECTED]> writes:
> > How about we include this and have configure somehow ensure the Solaris
> > users get it automatically?
>
> Hmm. I suppose there'd be no license issues with borrowing a BSD qsort.
> But I ca
Tom Lane wrote:
>
> Justin Clift <[EMAIL PROTECTED]> writes:
> > Mark kirkwood wrote:
> >> Indeed it is - obtained qsort.c from Freebsd CVS and rebuilt Postgresql :
> >> The query now takes 6 seconds instead of 1 hour ! Thanks for an
> >> excellent suggestion.
>
> > How about we include this and
Justin Clift <[EMAIL PROTECTED]> writes:
> Mark kirkwood wrote:
>> Indeed it is - obtained qsort.c from Freebsd CVS and rebuilt Postgresql :
>> The query now takes 6 seconds instead of 1 hour ! Thanks for an
>> excellent suggestion.
> How about we include this and have configure somehow ensure th
Hi Tom,
How about we include this and have configure somehow ensure the Solaris
users get it automatically?
There are a *bunch* of Solaris users out there.
:-)
Regards and best wishes,
Justin Clift
Mark kirkwood wrote:
>
> On Wed, 2002-04-03 at 04:02, Tom Lane wrote:
> >
> > Hmm. Where e
13 matches
Mail list logo
