Re: rethinking dense_alloc (HashJoin) as a memory context

On Wed, Jul 13, 2016 at 4:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra
>> <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>> 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.
>
> I think there's a lot, but I'm afraid most of them are in contexts
> (pun intended) where aset.c already works pretty well, ie it's a
> short-lived context anyway. The areas where we're having pain are
> where there are fairly long-lived contexts with lots of pfree traffic;
> certainly that seems to be the case in reorderbuffer.c. Because they're
> long-lived, you can't just write off the pfrees as ignorable.
>
> I wonder whether we could compromise by reducing the minimum "standard
> chunk header" to be just a pointer to owning context, with the other
> fields becoming specific to particular mcxt implementations. That would
> be enough to allow contexts to decide that pfree was a no-op, say, or that
> they wouldn't support GetMemoryChunkSpace(), without having to decree that
> misuse can lead to crashes. But that's still more than zero overhead
> per-chunk.

I think that would be worth doing. It's not perfect, and the extra 8
(or 4) bytes per chunk certainly do matter. On the other hand, it's
certainly better than what we're doing today, which basically closes
off all meaningful innovation in this area. If you are locked into
having a 16 byte chunk header that includes the size, the individual
memory context implementations don't have much latitude to vary their
behavior from what aset.c already does. You can change the policy for
allocating chunks from the operating system, and the way you try to
recycle chunks that have been freed, but that's about it. Removing
the size from the standard header would, I think, make it easier to
experiment more widely with alternative memory context implementations
and get a better idea what can be saved.

We can always think about further changes later, but this seems like a
good start.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company