Gregory Stark kirjoitti:
[aside, that said that may be a useful feature to have: a user option
to use
our internal heap sort instead of qsort. I'm thinking of users on
platforms
where libc's qsort either performs poorly or is buggy. Since we have
all the
code for heap sort there already
I'm not sure if this is good news or bad news. Either some kudos are due to
the gang that worked on the external sort performance or something's very
wrong with the qsort implementation in glibc because I'm seeing Postgres's
external sort perform better than qsort.
This is despite Postgres
I'm not sure if this is good news or bad news. Either some kudos are due to
the gang that worked on the external sort performance or something's very
wrong with the qsort implementation in glibc because I'm seeing Postgres's
external sort perform better than qsort.
And here's a really
: Friday, September 01, 2006 11:03 AM Eastern Standard Time
To: pgsql-hackers
Subject:[HACKERS] Sort performance
I'm not sure if this is good news or bad news. Either some kudos are due to
the gang that worked on the external sort performance or something's very
wrong with the qsort
Luke Lonergan [EMAIL PROTECTED] writes:
What version of pgsql?
Recent changes stripped the sort set down considerably in size in external
sort, I'm not sure the same is done if the data doesn't spill to disk.
This is a recent CVS checkout.
If you're referring to MinimalTuples I think that's
Gregory Stark [EMAIL PROTECTED] writes:
Mem RunsTime
1MB 18 8.25s
10MB 3 5.6s
100MB qsort 6.1s
I'm confused what this means exactly? Are you saying that in the first
two cases, there were 18 and 3 sorted runs
