|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Jeff Davis <pgsql(at)j-davis(dot)com>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: 9.5: Better memory accounting, towards memory-bounded HashAgg|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Jeff Davis <pgsql(at)j-davis(dot)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
|Next Message||Noah Misch||2014-08-29 14:15:47||Re: Removing dependency to wsock32.lib when compiling code on WIndows|
|Previous Message||Michael Paquier||2014-08-29 14:07:44||Re: Misleading error message in logical decoding for binary plugins|