Re: Printing backtrace of postgres processes

Поиск
Список
Период
Сортировка
От Christoph Berg
Тема Re: Printing backtrace of postgres processes
Дата
Msg-id Zdyooa_6QkCP3Lq7@msg.df7cb.de
обсуждение исходный текст
Ответ на Re: Printing backtrace of postgres processes  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Printing backtrace of postgres processes  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Re: Michael Paquier
> Something like this can be measured with a bunch of concurrent
> connections attempting connections and a very high rate, like pgbench
> with an empty script and -C, for local connections.

I tried that now. Mind that I'm not a benchmarking expert, and there's
been quite some jitter in the results, but I think there's a clear
trend.

Current head without and with the v28 patchset.
Command line:
pgbench -n -C -c 20 -j 20 -f empty.sql -T 30 --progress=2
empty.sql just contains a ";"
model name: 13th Gen Intel(R) Core(TM) i7-13700H

head:
tps = 2211.289863 (including reconnection times)
tps = 2113.907588 (including reconnection times)
tps = 2200.406877 (including reconnection times)
average: 2175

v28:
tps = 1873.472459 (including reconnection times)
tps = 2068.094383 (including reconnection times)
tps = 2196.890897 (including reconnection times)
average: 2046

2046 / 2175 = 0.941

Even if we regard the 1873 as an outlier, I've seen many vanilla runs
with 22xx tps, and not a single v28 run with 22xx tps. Other numbers I
collected suggested a cost of at least 3% for the feature.

Christoph



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

Предыдущее
От: Nikita Malakhov
Дата:
Сообщение: Re: Shared detoast Datum proposal
Следующее
От: Jacob Champion
Дата:
Сообщение: Re: WIP Incremental JSON Parser