On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra <tomas.von...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
