Re: qsort (was Re: Solaris) - Mailing list pgsql-general

From Tom Lane
Subject Re: qsort (was Re: Solaris)
Date
Msg-id 17287.1052368592@sss.pgh.pa.us
Whole thread Raw
In response to Re: qsort (was Re: Solaris)  (dalgoda@ix.netcom.com (Mike Castle))
List pgsql-general
dalgoda@ix.netcom.com (Mike Castle) writes:
> In a simple test function, like comparing two ints, then yes, the BSD
> implementation was faster.  But in a more complex function, say comparing
> strings, often times the glibc version was faster.  Why?  Because the
> time spent in the compare function became the overwhelming factor.

Interesting.

> So, I ask you this:  in places where qsort is used in PG, is it more likely
> to be used for simple comparisons or for complex comparisons that involve a
> mixture of strings and ints?

The only place that I think performance is likely to matter for is the
calls in tuplesort.c, which are expensive --- even if you end up calling
something as cheap as btint4cmp, there's a lot of overhead in between.
(I seem to recall hearing that Oracle expends effort trying to "compile"
code for tuple comparisons, but we don't ... yet ...)

  And, is it more likely to be called with
> datasets that are partially sorted or not?

I think that one's unanswerable.  It'd depend on the workload.

            regards, tom lane


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: How to determine a database cluster's LC_COLLATE setting?
Next
From: Abhishek Sharma
Date:
Subject: Postgresql on Solaris