Re: [HACKERS] Timsort performance, quicksort (was: Re: Memory usage during sorting)

2012-04-24 Thread Robert Haas
On Tue, Apr 24, 2012 at 7:16 PM, Peter Geoghegan 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 it's full of

Re: [HACKERS] Timsort performance, quicksort (was: Re: Memory usage during sorting)

2012-04-24 Thread Robert Haas
On Tue, Apr 24, 2012 at 12:51 PM, Peter Geoghegan wrote: > On 24 April 2012 16:17, Robert Haas 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 o

Re: [HACKERS] Timsort performance, quicksort (was: Re: Memory usage during sorting)

2012-04-24 Thread Robert Haas
On Tue, Apr 24, 2012 at 12:30 PM, Greg Stark wrote: > On Tue, Apr 24, 2012 at 4:17 PM, Robert Haas 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 a

Re: [HACKERS] Timsort performance, quicksort (was: Re: Memory usage during sorting)

2012-04-24 Thread Peter Geoghegan
On 24 April 2012 16:17, Robert Haas 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 (i.e. a re-creatable one

Re: [HACKERS] Timsort performance, quicksort (was: Re: Memory usage during sorting)

2012-04-24 Thread Greg Stark
On Tue, Apr 24, 2012 at 4:17 PM, Robert Haas 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 something like every

Re: [HACKERS] Timsort performance, quicksort (was: Re: Memory usage during sorting)

2012-04-24 Thread Robert Haas
On Wed, Apr 18, 2012 at 9:31 PM, Peter Geoghegan 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 Pro, if the strings a

[HACKERS] Timsort performance, quicksort (was: Re: Memory usage during sorting)

2012-04-18 Thread Peter Geoghegan
On 17 April 2012 13:19, Greg Stark 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 stability prop