Re: [HACKERS] Poor memory context performance in large hash joins - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Poor memory context performance in large hash joins
Date
Msg-id 28659.1488909999@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Poor memory context performance in large hash joins  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Poor memory context performance in large hash joins  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Poor memory context performance in large hash joins