Re: slab allocator performance issues - Mailing list pgsql-hackers

From Robert Haas
Subject Re: slab allocator performance issues
Date
Msg-id CA+TgmoYJSRvCM60t7tJ-1z186bZhJ-jsQuXpgXRpGfTmYOimJQ@mail.gmail.com
Whole thread Raw
In response to Re: slab allocator performance issues  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
On Fri, Sep 10, 2021 at 5:07 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> Turns out it's pretty difficult to benchmark this, because the results
> strongly depend on what the backend did before.

What you report here seems to be mostly cold-cache effects, with which
I don't think we need to be overly concerned. We don't want big
regressions in the cold-cache case, but there is always going to be
some overhead when a new backend starts up, because you've got to
fault some pages into the heap/malloc arena/whatever before they can
be efficiently accessed. What would be more concerning is if we found
out that the performance depended heavily on the internal state of the
allocator. For example, suppose you have two warmup routines W1 and
W2, each of which touches the same amount of total memory, but with
different details. Then you have a benchmark B. If you do W1-B and
W2-B and the time for B varies dramatically between them, then you've
maybe got an issue. For instance, it could indicate that the allocator
has issue when the old and new allocations are very different sizes,
or something like that.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_dump: Remove "blob" terminology
Next
From: Thom Brown
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions