"Josh Berkus" <josh@agliodbs.com> writes:
> sort_mem: My tests with 8.2 and DBT3 seemed to show that, due to
> limitations of our tape sort algorithm, allocating over 2GB for a single
> sort had no benefit. However, Magnus and others have claimed otherwise.
> Has this improved in 8.3?
Simon previously pointed out that we have some problems in our tape sort
algorithm with large values of work_mem. If the tape is "large enough" to
generate some number of output tapes then increasing the heap size doesn't buy
us any reduction in the future passes. And managing very large heaps is a
fairly large amount of cpu time itself.
The problem of course is that we never know if it's "large enough". We talked
at one point about having a heuristic where we start the heap relatively small
and double it (adding one row) whenever we find we're starting a new tape. Not
sure how that would work out though.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
