| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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 20:29:02 |
| Message-ID: | bb253bf7f836b63c5724b0695ec71d41084988ef.camel@j-davis.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
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.
> If we want to optimize memory usage, I think I'd first go for
> allocating
> the group's "firstTuple" together with all the AggStatePerGroupDatas.
That's a good idea.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2020-03-23 20:40:21 | Re: Option to dump foreign data in pg_dump |
| Previous Message | Alvaro Herrera | 2020-03-23 20:17:13 | Re: Option to dump foreign data in pg_dump |