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: Peter Geoghegan <pg(at)heroku(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: rethinking dense_alloc (HashJoin) as a memory context
Date: 2016-07-13 17:56:00
Message-ID: 22626.1468432560@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 13:37:55 -0400, Tom Lane wrote:
>> We already know that
>> that code has performance issues, cf bug #14231, so I suspect there's
>> a redesign in its future anyway.

> Note that it's not the slab allocators that is having problems, it's
> aset.c, iterating through all allocated blocks.

Well, my point is that that code is using allocation patterns that aset.c
isn't very well suited for. The slab allocator logic attempts to paper
over one part of that impedance mismatch, but we're seeing there's more.
I haven't looked at it closely enough to have a solution proposal.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2016-07-13 18:06:20 Re: \timing interval
Previous Message Andres Freund 2016-07-13 17:48:38 Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <