On Sat, 11 Jul 2020 at 12:47, David G. Johnston <david.g.johns...@gmail.com> wrote: > The multiplier seems strictly better than "rely on work_mem alone, i.e., do > nothing"; the detracting factor being one more GUC. Even if one wants to > argue the solution is ugly or imperfect the current state seems worse and a > more perfect option doesn't seem worth waiting for. The multiplier won't > make every single upgrade a non-event but it provides a more than sufficient > amount of control and in the worse case can be effectively ignored by setting > it to 1.0.
My argument wasn't related to if the new GUC should be a multiplier of work_mem or an absolute amount of memory. The point I was trying to make was that the solution to add a GUC to allow users to increase the memory Hash Join and Hash Agg for plans which don't contain any other nodes types that use work_mem is the same as doing nothing. As of today, those people could just increase work_mem. If we get hash_mem or some variant that is a multiplier of work_mem, then that user is in exactly the same situation for that plan. i.e there's no ability to increase the memory allowances for Hash Agg alone. If we have to have a new GUC, my preference would be hashagg_mem, where -1 means use work_mem and a value between 64 and MAX_KILOBYTES would mean use that value. We'd need some sort of check hook to disallow 0-63. I really am just failing to comprehend why we're contemplating changing the behaviour of Hash Join here. Of course, I understand that that node type also uses a hash table, but why does that give it the right to be involved in a change that we're making to try and give users the ability to avoid possible regressions with Hash Agg? David
