The current state, where HashAgg just blows up the memory, is just not reasonable, and we need to track the memory to fix that problem.
Meh. HashAgg could track its memory usage without loading the entire system with a penalty.
+1 to a solution like that, although I don't think that's doable without digging the info from memory contexts somehow.
I am sorry to ask questions unrelated to the subject, but how is tracking memory going to fix the HashAgg blow up problem? Is there a plan to make HashAgg not blow up (i.e. spill the hash table)?
The current state, where HashAgg just blows up the memory, is just not reasonable, and we need to track the memory to fix that problem.
Meh. HashAgg could track its memory usage without loading the entire system with a penalty.
+1 to a solution like that, although I don't think that's doable without digging the info from memory contexts somehow.
Jeff is right, we desperately need a solution and this is the place to start.
Tom's concern remains valid: we must not load the entire system with a penalty.
The only questions I have are:
* If the memory allocations adapt to the usage pattern, then we expect to see few memory chunk allocations. Why are we expecting "the entire system" to experience a penalty?
* If we do not manage our resources, how are we certain this does not induce a penalty? Not tracking memory could be worse than tracking it.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
