Re: rethinking dense_alloc (HashJoin) as a memory context

On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced
> his dislike of dense_alloc. I kinda agree with him that introducing "local
> allocators" may not be the best idea, and as dense_alloc was introduced by
> me I was playing with the idea to wrap this into a regular memory context,
> perhaps with some restrictions (e.g. no pfree). But I'm having trouble with
> that approach ...

I think that the "no pfree()" restriction would be necessary to get
the same benefit. But, doesn't that undermine the whole idea of making
it a memory context?

In my view, these "local allocators" are not so bad. They're a bit
ugly, but that seems to be worth it so far, and I don't think that
there is that much incidental complexity that could be encapsulated.
For a few modules, including tuplesort.c, the hash join code,
tuplestore.c, and possibly a couple of others, having precise control
over memory just seems like a good idea to me (i.e. doling it out from
some initial large batch palloc() allocations according to some
considerations about the relevant data structures, leaving a
cache-friendly layout).

I suspect that there are not that many places where it is worth it to
even contemplate batch or dense allocators, so I doubt that what we
will see all that many more instances of "local allocators".

--
Peter Geoghegan