Re: rethinking dense_alloc (HashJoin) as a memory context

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: rethinking dense_alloc (HashJoin) as a memory context
Дата
Msg-id 22626.1468432560@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: rethinking dense_alloc (HashJoin) as a memory context  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Следующее
От: Corey Huinker
Дата:
Сообщение: Re: \timing interval