Re: Memory Accounting v11

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Memory Accounting v11
Дата
Msg-id CAKJS1f-k5=JskSfnNEvVpXyJZ4CqJ393B6CiBBKG8-FPeen=AQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Memory Accounting v11  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: Memory Accounting v11  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
On 7 July 2015 at 20:23, David Rowley <david.rowley@2ndquadrant.com> wrote:
On 7 July 2015 at 18:59, Jeff Davis <pgsql@j-davis.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/
 PostgreSQL Development, 24x7 Support, Training & Services
 

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Improving log capture of TAP tests with IPC::Run
Следующее
От: Satoshi Nagayasu
Дата:
Сообщение: Fix to expose a GUC variable, Log_disconnections, to outside of postgres.c