| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Pengzhou Tang <ptang(at)pivotal(dot)io>, pgsql-hackers(at)postgresql(dot)org, Jeff Davis <pgsql(at)j-davis(dot)com>, Andrew Gierth <rhodiumtoad(at)postgresql(dot)org> |
| Subject: | Re: Additional size of hash table is alway zero for hash aggregates |
| Date: | 2020-03-12 23:11:16 |
| Message-ID: | 20200312231116.GH29065@telsasoft.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 12, 2020 at 12:16:26PM -0700, Andres Freund wrote:
> On 2020-03-12 16:35:15 +0800, Pengzhou Tang wrote:
> > When reading the grouping sets codes, I find that the additional size of
> > the hash table for hash aggregates is always zero, this seems to be
> > incorrect to me, attached a patch to fix it, please help to check.
>
> 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 found that it was working when Andres implemented TupleHashTable, but broke
at:
| b5635948ab Support hashed aggregation with grouping sets.
So affects v11 and v12. entrysize isn't used for anything else.
--
Justin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2020-03-12 23:40:15 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
| Previous Message | Alvaro Herrera | 2020-03-12 21:53:11 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |