Re: Avoid stack frame setup in performance critical routines using tail calls

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Avoid stack frame setup in performance critical routines using tail calls
Дата
Msg-id 20230719085236.jltxal2eztqrprfg@awork3.anarazel.de
обсуждение исходный текст
Ответ на Avoid stack frame setup in performance critical routines using tail calls  (Andres Freund <andres@anarazel.de>)
Ответы Re: Avoid stack frame setup in performance critical routines using tail calls  (David Rowley <dgrowleyml@gmail.com>)
Re: Avoid stack frame setup in performance critical routines using tail calls  (John Naylor <john.naylor@enterprisedb.com>)
Список pgsql-hackers
Hi,

David and I were chatting about this patch, in the context of his bump
allocator patch.  Attached is a rebased version that is also split up into two
steps, and a bit more polished.

I wasn't sure what a good test was. I ended up measuring
  COPY pgbench_accounts TO '/dev/null' WITH (FORMAT 'binary');
of a scale 1 database with pgbench:

c=1;pgbench -q -i -s1 && pgbench  -n -c$c -j$c -t100 -f <(echo "COPY pgbench_accounts TO '/dev/null' WITH (FORMAT
'binary');")

    average latency
HEAD:   33.865 ms
01:     32.820 ms
02:     29.934 ms

The server was pinned to the one core, turbo mode disabled.  That's a pretty
nice win, I'd say.  And I don't think this is actually the most allocator
bound workload, I just tried something fairly random...


Greetings,

Andres Freund

Вложения

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

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: unrecognized node type while displaying a Path due to dangling pointer
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Use of additional index columns in rows filtering