From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pengzhou Tang <ptang(at)pivotal(dot)io>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Additional size of hash table is alway zero for hash aggregates |
Date: | 2020-03-23 21:00:37 |
Message-ID: | 20200323210037.f7cfxchfjihbwxo5@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-03-23 13:29:02 -0700, Jeff Davis wrote:
> On Sat, 2020-03-21 at 18:26 -0700, Andres Freund wrote:
> > I don't see how? That'd require making the hash bucket addressing
> > deal
> > with variable sizes, which'd be bad for performance reasons. Since
> > there
> > can be a aggstate->numtrans AggStatePerGroupDatas for each hash table
> > entry, I don't see how to avoid a variable size?
>
> It would not vary for a given hash table. Do you mean the compile-time
> specialization (of simplehash.h) would not work any more?
Yes.
> If we aren't storing the "additional" inline in the hash entry, I don't
> see any purpose for the argument to BuildTupleHashTableExt(), nor the
> purpose of the "entrysize" field of TupleHashTableData.
Yea, that was my conclusion too. It looked like Andrew was going to
commit a fix, but that hasn't happened yet.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-03-23 21:24:49 | Re: Missing errcode() in ereport |
Previous Message | Teja Mupparti | 2020-03-23 20:56:59 | Corruption during WAL replay |