Re: slab allocator performance issues

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: slab allocator performance issues
Дата
Msg-id CA+TgmoYJSRvCM60t7tJ-1z186bZhJ-jsQuXpgXRpGfTmYOimJQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: slab allocator performance issues  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_dump: Remove "blob" terminology
Следующее
От: Thom Brown
Дата:
Сообщение: Re: [PoC] Reducing planning time when tables have many partitions