Re: rethinking dense_alloc (HashJoin) as a memory context

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: rethinking dense_alloc (HashJoin) as a memory context
Date: 2016-07-13 21:04:25
Message-ID: 1834.1468443865@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-07-13 21:04:49 Re: Simplifying the interface of UpdateMinRecoveryPoint
Previous Message Michael Paquier 2016-07-13 21:02:55 Re: Header and comments describing routines in incorrect shape in visibilitymap.c