Re: Printing backtrace of postgres processes - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: Printing backtrace of postgres processes
Date
Msg-id Zdyooa_6QkCP3Lq7@msg.df7cb.de
Whole thread Raw
In response to Re: Printing backtrace of postgres processes  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Printing backtrace of postgres processes  (Michael Paquier <michael@paquier.xyz>)
List 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 by date:

Previous
From: Nikita Malakhov
Date:
Subject: Re: Shared detoast Datum proposal
Next
From: Jacob Champion
Date:
Subject: Re: WIP Incremental JSON Parser