Re: 9.5: Better memory accounting, towards memory-bounded HashAgg

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
Дата
Msg-id 17422.1409321554@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: 9.5: Better memory accounting, towards memory-bounded HashAgg  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: 9.5: Better memory accounting, towards memory-bounded HashAgg  (Tomas Vondra <tv@fuzzy.cz>)
Re: 9.5: Better memory accounting, towards memory-bounded HashAgg  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> I have a new approach to the patch which is to call a callback at each
> block allocation and child contexts inherit the callback from their
> parents. The callback could be defined to simply dereference and
> increment its argument, which would mean block allocations anywhere in
> the hierarchy are incrementing the same variable, avoiding the need to
> traverse the hierarchy.

Cute, but it's impossible to believe that a function call isn't going
to be *even more* overhead than what you've got now.  This could only
measure out as a win when the feature is going unused.

What about removing the callback per se and just keeping the argument,
as it were.  That is, a MemoryContext has a field of type "size_t *"
that is normally NULL, but if set to non-NULL, then we increment the
pointed-to value for pallocs and decrement for pfrees.

One thought in either case is that we don't have to touch the API for
MemoryContextCreate: rather, the feature can be enabled in a separate
call after making the context.
        regards, tom lane



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Misleading error message in logical decoding for binary plugins
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Removing dependency to wsock32.lib when compiling code on WIndows