On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > I think the MemoryContext API may not be right abstraction for this.
+1. The MemoryContext API is little short of an absolute bar to implementing an allocator that works significantly differently than aset.c, and that's a shame because aset.c is great for little tiny contexts that don't live very long and sucks for everything else. In particular, it sucks for anything that does a large number of allocations. It's also hostile to any kind of context stored inside a DSM segment, since those don't have a fixed addresses across all backends that share them. The alternative that I played with a while back when I was working on the sb_alloc allocator was to set things up so that we could identify the memory context based on the pointer address rather than the chunk header. That's a whole lot better for memory efficiency since you can squeeze out the chunk headers, but it inevitably slows down pfree. What's not clear to me is to what extent slowing down pfree is an acceptable price for improving the behavior in other ways. I wonder how many of the pfree calls in our current codebase are useless or even counterproductive, or could be made so. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers