Re: Additional size of hash table is alway zero for hash aggregates - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Additional size of hash table is alway zero for hash aggregates
Date
Msg-id 871rpxds54.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Additional size of hash table is alway zero for hash aggregates  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Additional size of hash table is alway zero for hash aggregates  (Andres Freund <andres@anarazel.de>)
Re: Additional size of hash table is alway zero for hash aggregates  (Pengzhou Tang <ptang@pivotal.io>)
Re: Additional size of hash table is alway zero for hash aggregates  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
>>>>> "Justin" == Justin Pryzby <pryzby@telsasoft.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.

Or maybe if work_mem had been reduced between plan time and execution
time....

So this is unlikely to be causing any issue in practice, so backpatching
may not be called for.

I'll deal with it in HEAD only, unless someone else has a burning desire
to take it.

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Berserk Autovacuum (let's save next Mandrill)
Next
From: Andres Freund
Date:
Subject: Re: Additional size of hash table is alway zero for hash aggregates