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

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
Date: 2014-08-29 14:12:34
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

In response to


Browse pgsql-hackers by date

  From Date Subject
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