Re: rethinking dense_alloc (HashJoin) as a memory context - Mailing list pgsql-hackers

From Tom Lane
Subject Re: rethinking dense_alloc (HashJoin) as a memory context
Date
Msg-id 22626.1468432560@sss.pgh.pa.us
Whole thread Raw
In response to Re: rethinking dense_alloc (HashJoin) as a memory context  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Next
From: Corey Huinker
Date:
Subject: Re: \timing interval