> > So basically, glibc's qsort is bad enough that even a
> > 10%-more-comparisons advantage doesn't save it.
> Do those numbers look very different if you have lots of
> columns or if you're sorting on something like an array or a ROW?
Imho, that also is an argument for using our own qsort.
I
Sorry. Stupid question. I didn't realize SQL allowed for the column
to be identified by number. I've never seen that before. :-)
Cheers,
mark
On Tue, Oct 03, 2006 at 06:47:35PM -0400, [EMAIL PROTECTED] wrote:
> On Tue, Oct 03, 2006 at 03:44:38PM -0400, Tom Lane wrote:
> > select count(*) from
>
[EMAIL PROTECTED] writes:
> I'm wondering whether 'order by 1' is representative of a real sort, from
> the perspective of benchmarks.
Better re-read
http://www.postgresql.org/docs/8.1/static/sql-select.html#SQL-ORDERBY
regards, tom lane
---(end of
On Tue, Oct 03, 2006 at 03:44:38PM -0400, Tom Lane wrote:
> select count(*) from
> (select random()::text from generate_series(1,100) order by 1) ss;
> ...
> postgres=# select count(*) from (select random() from
> generate_series(1,100) order by 1) ss;
I'm wondering whether 'order by 1'
+1
- Luke
On 10/3/06 2:58 PM, "Mark Kirkwood" <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>> Neil Conway <[EMAIL PROTECTED]> writes:
>>> Given the time that has been spent working around
>>> the braindamaged behavior of qsort() on various platforms, I would be
>>> more inclined to *always* use
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
Given the time that has been spent working around
the braindamaged behavior of qsort() on various platforms, I would be
more inclined to *always* use our qsort() instead of the platform's
version.
I've been heard to argue against that in
Gregory Stark <[EMAIL PROTECTED]> writes:
> Actually what I was more concerned about was things like on data structures
> with complex comparison routines. Things like sorting on arrays or ROWs.
The important point here is that blowing up the cost of the comparison
function by a factor of 3 (by sw
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I was planning to do it right now, on the grounds that #2 and #3 are bug
>> fixes, and that fixing the existing memory leakage hazard is a good
>> thing too.
> I am OK with doing it now, but calling it a bug fix seems like a
> stretch.
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On Tue, 2006-10-03 at 15:44 -0400, Tom Lane wrote:
> >> 1. Switch to using port/qsort.c all the time.
> >> 2. Add a "qsort_arg" function that is identical to qsort except it also
> >> passes a void pointer through to the comparison funct
Tom Lane <[EMAIL PROTECTED]> writes:
> So basically, glibc's qsort is bad enough that even a
> 10%-more-comparisons advantage doesn't save it.
Actually what I was more concerned about was things like on data structures
with complex comparison routines. Things like sorting on arrays or ROWs.
For
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2006-10-03 at 15:44 -0400, Tom Lane wrote:
>> 1. Switch to using port/qsort.c all the time.
>> 2. Add a "qsort_arg" function that is identical to qsort except it also
>> passes a void pointer through to the comparison function. This will
>> allow u
On Tue, 2006-10-03 at 15:44 -0400, Tom Lane wrote:
> I propose that we do the following:
>
> 1. Switch to using port/qsort.c all the time.
> 2. Add a "qsort_arg" function that is identical to qsort except it also
>passes a void pointer through to the comparison function. This will
>allow
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
Given the time that has been spent working around
the braindamaged behavior of qsort() on various platforms, I would be
more inclined to *always* use our qsort() instead of the platform's
version.
I propose that we do the following:
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Is it time to "remove" PG qsort and use libc version for solaris 9, 10...?
I have no particular desire to introduce a version number check until we
have to. If you can show that the newer versions have a qsort that
substantially *out-p
Neil Conway <[EMAIL PROTECTED]> writes:
> Given the time that has been spent working around
> the braindamaged behavior of qsort() on various platforms, I would be
> more inclined to *always* use our qsort() instead of the platform's
> version.
I spent a bit of time looking into why we hadn't chos
Neil Conway <[EMAIL PROTECTED]> writes:
> Given the time that has been spent working around
> the braindamaged behavior of qsort() on various platforms, I would be
> more inclined to *always* use our qsort() instead of the platform's
> version.
I've been heard to argue against that in the past, bu
On Tue, 2006-10-03 at 10:48 -0400, Tom Lane wrote:
> I have no particular desire to introduce a version number check until we
> have to. If you can show that the newer versions have a qsort that
> substantially *out-performs* ours
Are there any platform-local variants of qsort() that substantiall
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Is it time to "remove" PG qsort and use libc version for solaris 9, 10...?
I have no particular desire to introduce a version number check until we
have to. If you can show that the newer versions have a qsort that
substantially *out-performs* ours, it
Postgres has own implementation of qsort. It is used only for Solaris,
because in some cases Solaris implementation was terrible slow.
Now, New qsort is present in the Solaris from version 9 update 6 and I
performed some quick test and the speed is very similarly with pg
implementation see bel
19 matches
Mail list logo
