Re: Memory Accounting v11

On 7 July 2015 at 20:23, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:

> On 7 July 2015 at 18:59, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
>>
>>
> > One other thing that I don't remember seeing discussed would be to
>> > just store a List in each context which would store all of the
>> > mem_allocated's that need to be updated during each allocation and
>> > deallocation of memory. The list would be setup once when the context
>> > is created. When a child context is setup we'd just loop up the parent
>> > context chain and list_concat() all of the parent's lists onto the
>> > child's lists. Would this method add too much overhead when a context
>> > is deleted? Has this been explored already?
>> >
>> That's a good idea, as it would be faster than recursing. Also, the
>> number of parents can't change, so we can just make an array, and that
>> would be quite fast to update. Unless I'm missing something, this sounds
>> like a nice solution. It would require more space in MemoryContextData,
>> but that might not be a problem.
>>
>>
> Oh an array is even better, but why more space? won't it just be a pointer
> to an array? It can be NULL if there's nothing to track. Sounds like it
> would be the same amount of space, at least on a 64 bit machine.
>
>
I'd imagine that the first element of the array could just store the length
of it. The type might be slightly wider for what you need for an array
length, but this'll save having an extra field in the struct for it.

Are you going to implement this? or are you happy with the single level
context tracking is the right thing?
I'm going to mark the patch as waiting on author for now.

Regards

David Rowley

--
David Rowley http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Training & Services