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

From: Pengzhou Tang <ptang(at)pivotal(dot)io>
To: Andres Freund <andres(at)anarazel(dot)de>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: Additional size of hash table is alway zero for hash aggregates
Date: 2020-03-14 03:13:46
Message-ID: CAG4reASZc61PzNUd0p3qgrAgYpZtNxwHhcXipzUjQdhcJ2iaOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks, Andres Freund and Andres Gierth.

To be related, can I invite you to help to review the parallel grouping sets
patches? It will be very great to hear some comments from you since you
contributed most of the codes for grouping sets.

the thread is
https://www.postgresql.org/message-id/CAG4reAQ8rFCc%2Bi0oju3VjaW7xSOJAkvLrqa4F-NYZzAG4SW7iQ%40mail.gmail.com

Thanks,
Pengzhou

On Fri, Mar 13, 2020 at 3:16 AM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
>
> 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?
>
> Greetings,
>
> Andres Freund
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2020-03-14 07:07:24 Re: proposal: new polymorphic types - commontype and commontypearray
Previous Message Pengzhou Tang 2020-03-14 03:01:33 Re: Parallel grouping sets