On 07/19/2016 07:27 AM, Andres Freund wrote:
> Hi,
>
> On 2016-07-19 07:04:43 +0200, Tomas Vondra wrote:
>> So, I've spent a few hours experimenting with this idea, and I
>> believe it seems like a good way forward. Attached is an early WIP
>> patch that does this:
>
> Cool! Thanks for looking into this.
>
>
>> I'm not sure whether the SlabContext is needed here - perhaps
>> AllocSets would do equally well, at least in this case. I however
>> wonder whether the existing local slab cache can actually improve
>> anything, because what I see is a long sequence of pallocs()
>> followed by a long sequence of pfrees(), which makes any reuse
>> impossible. But I guess there are other cases where the palloc()
>> and pfree() calls are mixed.
>
> In something more oltp like you'll see exactly that. IIRC, in
> pgbench, we pretty much never allocate for the slab allocated stuff,
> after some warmup.
Yeah. Haven't done much testing at night. I think we'll need a set of
test cases to validate the changes. We certainly don't want to improve
one case and regress two others.
>
>> The other thing is that splitting the tuple context into two parts
>> seems a bit wasteful - this mostly follows the MaxHeapTupleSize
>> idea from the existing slab code, but how many tuples actually are
>> this big?
>
> The issue is that allocating them differently sized leads to massive
> memory fragmentation over time.
>
Sure, in all allocators we basically trade space and time efficiency. If
we could get some apriori some estimate of the tuple size, we could
probably tune this. It's just that ~8kB per tuple seems a bit too high.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services