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
|
Список | 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 по дате отправления: