Re: [HACKERS] Automatically setting work_mem

On Fri, 2006-04-21 at 23:07 -0400, Bruce Momjian wrote:
> Where are we on this patch?

Well the patches work and have been performance tested, with results
posted. Again, the title of this thread doesn't precisely describe the
patch any longer.

The question is do people believe there is benefit in reducing the
amount of memory for the final sort phase, and if so, to what level?

I still do, for multi-user systems. Releasing unused memory from a large
CREATE INDEX will allow that memory to be swapped out, even if the brk
point can't be changed. For large queries with multiple sorts the memory
can be reused immediately.

The patch does sound somewhat obscure and a corner case, I grant you,
but the more memory you give a sort the smaller number of runs you are
likely to have. So the situation of having enough memory to, say, merge
500 runs at the same time as having less than 10 runs is actually IMHO
the common case.

Patch now is: "Reducing memory usage in sort final merge phase."

[I've also completed Cascade Merge sort ready for unit testing, but will
not be completing that for a few weeks yet]

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com/