9.5: Better memory accounting, towards memory-bounded HashAgg

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема 9.5: Better memory accounting, towards memory-bounded HashAgg
Дата
Msg-id 1407012053.15301.53.camel@jeff-desktop
обсуждение исходный текст
Ответы Re: 9.5: Better memory accounting, towards memory-bounded HashAgg  (Peter Geoghegan <pg@heroku.com>)
Re: 9.5: Better memory accounting, towards memory-bounded HashAgg  (Robert Haas <robertmhaas@gmail.com>)
Re: 9.5: Better memory accounting, towards memory-bounded HashAgg  (Tomas Vondra <tv@fuzzy.cz>)
Список pgsql-hackers
Attached is a patch that explicitly tracks allocated memory (the blocks,
not the chunks) for each memory context, as well as its children.

This is a prerequisite for memory-bounded HashAgg, which I intend to
submit for the next CF. Hashjoin tracks the tuple sizes that it adds to
the hash table, which is a good estimate for Hashjoin. But I don't think
it's as easy for Hashagg, for which we need to track transition values,
etc. (also, for HashAgg, I expect that the overhead will be more
significant than for Hashjoin). If we track the space used by the memory
contexts directly, it's easier and more accurate.

I did some simple pgbench select-only tests, and I didn't see any TPS
difference.

Regards,
    Jeff Davis


Вложения

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

Предыдущее
От: John Cochran
Дата:
Сообщение: Looked at TODO:Considering improving performance of computing CHAR() value lengths
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: B-Tree support function number 3 (strxfrm() optimization)