Date: Mon, 22 Jul 2019 18:16:58 +0200
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Jeff Davis <pgsql@j-davis.com>, pgsql-hackers@postgresql.org
Subject: Re: Memory Accounting
Message-ID: <20190722161658.ryo6lbgead2tijew@development>
References: <027a129b8525601c6a680d27ce3a7172dab61aab.camel@j-davis.com>
 <8456dbe6-2245-6a6d-03af-bb62d1615782@iki.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <8456dbe6-2245-6a6d-03af-bb62d1615782@iki.fi>
User-Agent: NeoMutt/20180716-1444-295967-dirty
Precedence: bulk

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