Re: rethinking dense_alloc (HashJoin) as a memory context

On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)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