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
Re: 9.5: Better memory accounting, towards memory-bounded HashAgg |
| Список | 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 по дате отправления: