Re: Memory Accounting
От | Tomas Vondra |
---|---|
Тема | Re: Memory Accounting |
Дата | |
Msg-id | 20190722161658.ryo6lbgead2tijew@development обсуждение исходный текст |
Ответ на | Re: Memory Accounting (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: Memory Accounting
|
Список | pgsql-hackers |
On Mon, Jul 22, 2019 at 11:30:37AM +0300, Heikki Linnakangas wrote: >On 18/07/2019 21:24, Jeff Davis wrote: >>Previous discussion: >>https://postgr.es/m/1407012053.15301.53.camel%40jeff-desktop >> >>This patch introduces a way to ask a memory context how much memory it >>currently has allocated. Each time a new block (not an individual >>chunk, but a new malloc'd block) is allocated, it increments a struct >>member; and each time a block is free'd, it decrements the struct >>member. So it tracks blocks allocated by malloc, not what is actually >>used for chunks allocated by palloc. >> >>The purpose is for Memory Bounded Hash Aggregation, but it may be >>useful in more cases as we try to better adapt to and control memory >>usage at execution time. > >Seems handy. > Indeed. >>* I changed it to only update mem_allocated for the current context, >>not recursively for all parent contexts. It's now up to the function >>that reports memory usage to recurse or not (as needed). > >Is that OK for memory bounded hash aggregation? Might there be a lot >of sub-contexts during hash aggregation? > There shouldn't be, at least not since b419865a814abbc. There might be cases where custom aggregates still do that, but I think that's simply a design we should discourage. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: