Peter Geoghegan <> writes:
> On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra
> <> 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?

The other thing that doesn't seem to square at all with a general-purpose
memory context is the desire to walk through the stored tuples directly,
knowing that they are adjacent.  That means nothing else can be allocated
via the same mechanism.  So I tend to agree that if we accept Tomas' three
requirements as non-negotiable, then trying to make the allocator match
the MemoryContext API is probably impractical.

My feeling at this point is that we should leave it alone until/unless
we see similar requirements elsewhere, and then look to see if we can
derive a common abstraction.  I always find that it's easier to design
APIs based on concrete use-cases than on guesses about what will be

I wonder though if we don't already have another similar use-case in
the ad-hoc "slab allocators" in reorderbuffer.c.  We already know that
that code has performance issues, cf bug #14231, so I suspect there's
a redesign in its future anyway.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to