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/ ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
