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

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





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Option to dump foreign data in pg_dump
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Option to dump foreign data in pg_dump