Re: Additional size of hash table is alway zero for hash aggregates

On Fri, Mar 13, 2020 at 8:34 AM Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
wrote:

> >>>>> "Justin" == Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
>
> > On Thu, Mar 12, 2020 at 12:16:26PM -0700, Andres Freund wrote:
> >> Indeed, that's incorrect. Causes the number of buckets for the
> >> hashtable to be set higher - the size is just used for that. I'm a
> >> bit wary of changing this in the stable branches - could cause
> >> performance changes?
>
> I think (offhand, not tested) that the number of buckets would only be
> affected if the (planner-supplied) numGroups value would cause work_mem
> to be exceeded; the planner doesn't plan a hashagg at all in that case
> unless forced to (grouping by a hashable but not sortable column). Note
> that for various reasons the planner tends to over-estimate the memory
> requirement anyway.
>
>
That makes sense, thanks