On Mon, Jul 13, 2020 at 9:47 AM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > I'm in favor of hash_mem_multiplier. I think a >1 default is more > sensible than =1 in the long run, but if strategic vote is what we're > doing, then I support the =1 option.
Attached is a WIP patch implementing hash_mem_multiplier, with 1.0 as the GUC's default value (i.e. the patch introduces no behavioral changes by default). The first patch in the series renames some local variables whose name is made ambiguous by the second, main patch. Since the patch doesn't add a new work_mem-style GUC, but existing consumers of work_mem expect something like that, the code is structured in a way that allows the planner and executor to pretend that there really is a work_mem-style GUC called hash_mem, which they can determine the value of by calling the get_hash_mem() function. This seemed like the simplest approach overall. I placed the get_hash_mem() function in nodeHash.c, which is a pretty random place for it. If anybody has any better ideas about where it should live, please say so. ISTM that the planner changes are where there's mostly likely to be problems. Reviewers should examine consider_groupingsets_paths() in detail. -- Peter Geoghegan
v2-0001-Rename-hash_mem-local-variable.patch
Description: Binary data
v2-0002-Add-hash_mem_multiplier-GUC.patch
Description: Binary data
