Re: [HACKERS] Poor memory context performance in large hash joins

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Poor memory context performance in large hash joins
Дата
Msg-id 28659.1488909999@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Poor memory context performance in large hash joins  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] Poor memory context performance in large hash joins  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
>>> On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
>>>> Concretely, something like the attached.  This passes regression tests
>>>> but I've not pushed on it any harder than that.

> I think we should go forward with something like this patch in all
> branches, and only use Tomas' patch in master, because they're
> considerably larger.

While I'm willing to back-patch the proposed patch to some extent,
I'm a bit hesitant to shove it into all branches, because I don't
think that usage patterns that create a problem occurred till recently.
You won't get a whole lot of standalone-block allocations unless you
have code that allocates many chunks bigger than 8K without applying a
double-the-request-each-time type of strategy.  And even then, it doesn't
hurt unless you try to resize those chunks, or delete them in a non-LIFO
order.

The hashjoin issue is certainly new, and the reorderbuffer issue can't
go back further than 9.4.  So my inclination is to patch back to 9.4
and call it good.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Poor memory context performance in large hash joins