Re: rethinking dense_alloc (HashJoin) as a memory context

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2016-07-13 16:39:58 -0400, Tom Lane wrote:
>> 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.

> FWIW, hacking up the aset/mcxt.c to use a trivial allocator with less
> overhead (i.e. just hand out sections out of a continuous block of
> memory) results in a noticeable speedup in parse heavy workloads. It's a
> bit ugly though, because of the amount of retail pfrees in random
> places.

Yeah, both the parser and planner are already in the "palloc a lot and
don't worry too much about pfrees" camp. I think they could both benefit
from an allocator that ignores pfree and doesn't round up request sizes
(except for MAXALIGN). I'm not sure how much of the rest of the system
would like that behavior, though.

The design intention behind mcxt.c/aset.c was always that we'd have
multiple allocators (multiple context types). I'm surprised that we've
gone this long without following through on that.

regards, tom lane