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 anyway
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
"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
CTED]
Sent: 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
> 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 pe
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 extern
