On Fri, Nov 24, 2017 at 4:54 PM, Tom Lane wrote:
>> It doesn't seem that crazy to expose aset.c's overhead size to client
>> code does it? Most client code wouldn't care, but things that are
>> doing something closer to memory allocator work themselves like
>> dense_alloc could care. It could de
Thomas Munro writes:
> On Tue, Nov 29, 2016 at 6:27 AM, Tom Lane wrote:
>> We could imagine providing an mmgr API function along the lines of "adjust
>> this request size to the nearest thing that can be allocated efficiently".
>> That would avoid the need for callers to know about aset.c overhea
On Tue, Nov 29, 2016 at 6:27 AM, Tom Lane wrote:
> Thomas Munro writes:
>> I bet other allocators also do badly with "32KB plus a smidgen". To
>> minimise overhead we'd probably need to try to arrange for exactly
>> 32KB (or some other power of 2 or at least factor of common page/chunk
>> size?)
