On 10/20/2016 04:43 PM, Robert Haas wrote:
On Tue, Oct 18, 2016 at 6:27 PM, Petr Jelinek <p...@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

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.


Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to