Re: Using quicksort for every external sort run - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Using quicksort for every external sort run
Date
Msg-id CAM-w4HMBpLLs1HiuiSz3MnGB9B9XVcJxpNGAeJeawOLpB-zEqw@mail.gmail.com
Whole thread Raw
In response to Re: Using quicksort for every external sort run  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Using quicksort for every external sort run  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Hm. Here is a log-log chart of those results (sorry for html mail). I'm not really sure if log-log is the right tool to use for a O(nlog(n)) curve though. 

I think the take-away is that this is outside the domain where any interesting break points occur. Maybe run more tests on the low end to find where the tapesort can generate a single tape and avoid the merge and see where the discontinuity is with quicksort for the various work_mem sizes. 

And can you calculate an estimate where the domain would be where multiple passes would be needed for this table at these work_mem sizes? Is it feasible to test around there?
Inline image 1




--
greg
Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Memory prefetching while sequentially fetching from SortTuple array, tuplestore
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: PL/Pythonu - function ereport