On Wed, Apr 18, 2012 at 9:31 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Thoughts?
Interesting work. I thought about trying to code up timsort at one
point, but I've been running short of round tuits.
I did some quick tests of quicksort using half a million random
strings. On my MacBook
On Tue, Apr 24, 2012 at 4:17 PM, Robert Haas robertmh...@gmail.com wrote:
Based on that, I'm inclined to propose rejiggering things so that the
presorted-input check runs only at the top level, and not during any
recursive steps.
Just a thought. What about running only every nth step. Maybe
On 24 April 2012 16:17, Robert Haas robertmh...@gmail.com wrote:
If they are in sorted order with an empty string
appended onto the end, it takes about 25 seconds.
That's exactly what I'd have expected, but was surprised to have not
found with my own test. Perhaps it was same kind of fluke
On Tue, Apr 24, 2012 at 12:30 PM, Greg Stark st...@mit.edu wrote:
On Tue, Apr 24, 2012 at 4:17 PM, Robert Haas robertmh...@gmail.com wrote:
Based on that, I'm inclined to propose rejiggering things so that the
presorted-input check runs only at the top level, and not during any
recursive
On Tue, Apr 24, 2012 at 12:51 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 24 April 2012 16:17, Robert Haas robertmh...@gmail.com wrote:
If they are in sorted order with an empty string
appended onto the end, it takes about 25 seconds.
That's exactly what I'd have expected, but was
On Tue, Apr 24, 2012 at 7:16 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
That makes sense to me, but obviously more data is needed here.
What more data do you think is needed? I've been suspicious of that
code since the first time I looked at it, and I'm now fairly well
convinced that
On 17 April 2012 13:19, Greg Stark st...@mit.edu wrote:
All in all I think it's handier to have a stable ORDER BY sort than an
unstable one though. So I'm not necessarily opposed to it even if it
means we're stuck using a stable sort indefinitely.
I think it might be useful to disguard the
