On 10/20/2016 04:43 PM, Robert Haas wrote:
> On Tue, Oct 18, 2016 at 6:27 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:
>> I agree though that the usability beyond the ReoderBuffer is limited
>> because everything that will want to use it for part of allocations will
>> get much more complicated by the fact that it will have to use two
>> different allocators.
>>
>> I was wondering if rather than trying to implement new allocator we
>> should maybe implement palloc_fixed which would use some optimized
>> algorithm for fixed sized objects in our current allocator. The
>> advantage of that would be that we could for example use that for things
>> like ListCell easily (memory management of which I see quite often in
>> profiles).
>
> The sb_alloc allocator I proposed a couple of years ago would work
> well for this case, I think.
>
Maybe, but it does not follow the Memory Context design at all, if I
understand it correctly. I was willing to give it a spin anyway and see
how it compares to the two other allocators, but this is a significant
paradigm shift and certainly much larger step than what I proposed.
I'm not even sure it's possible to implement a MemoryContext based on
the same ideas as sb_alloc(), because one of the important points of
sb_alloc design seems to be throwing away the chunk header. While that
may be possible, it would certainly affect the whole tree (not just the
reorderbuffer bit), and it'd require way more work.
Moreover, the two allocators I proposed significantly benefit from the
"same lifespan" assumption. I don't think sb_alloc can do that.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
