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 по дате отправления:

Предыдущее
От: Teja Mupparti
Дата:
Сообщение: Corruption during WAL replay
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Missing errcode() in ereport