Re: Additional size of hash table is alway zero for hash aggregates
| От | Andres Freund |
|---|---|
| Тема | Re: Additional size of hash table is alway zero for hash aggregates |
| Дата | |
| Msg-id | 20200323210037.f7cfxchfjihbwxo5@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: Additional size of hash table is alway zero for hash aggregates (Jeff Davis <pgsql@j-davis.com>) |
| Список | 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
В списке pgsql-hackers по дате отправления: