Re: qsort, once again - Mailing list pgsql-hackers

From Tom Lane
Subject Re: qsort, once again
Date
Msg-id 19857.1142973455@sss.pgh.pa.us
Whole thread Raw
In response to Re: qsort, once again  (Greg Stark <gsstark@mit.edu>)
Responses Re: qsort, once again  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> That looks better both on average and in the worst case. Are the time
> constants that much worse that the merge sort still takes longer?

Keep in mind that this is only counting the number of
comparison-function calls; it's not accounting for any other effects.
In particular, for a large sort operation quicksort might win because of
its more cache-friendly memory access patterns.

The whole question of our qsort vs the system library's qsort probably
needs to be revisited, however, now that we've identified and fixed this
particular performance issue.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [GENERAL] A real currency type
Next
From: Andrew Dunstan
Date:
Subject: Re: [GENERAL] A real currency type