Hi hackers! I did a lot of benchmarks in last time, and more are incoming. While benchmarking with pgbench I keep hitting the same annoyance: the final report says only "latency average" and "latency stddev", which tells nothing about the distribution. p95/p99 is usually what you actually want when evaluating tail latency.
Today the answer is to run with -l and post-process the log, but logging itself perturbs subsequent transactions (fsync'ed writes on the hot path), and requires a second step. What if we add new option, smth like --latency-percentiles[=p1,p2,...], which extends the final reports with: latency min = 4.114 ms latency max = 15.213 ms latency p50 = 6.097 ms latency p95 = 12.211 ms latency p99 = 13.883 ms Main design points, kept deliberately simple for a first version: - percentiles are estimated from a fixed-size log-scale histogram (32 sub-buckets per octave, 4 KB, zero allocations, a few ops per transaction; no overhead at all when the option is not given). A more clever estimator (t-digest and friends) can replace it later behind the same interface, but seemed like overkill to start with; - the histogram is a separate member of StatsData next to the latency SimpleStats, so existing stats structs/log files/per-command table and the default output stay untouched; - semantics match existing latency stats: successful, non-skipped transactions only; Accuracy vs a sorted -l log of the same run: p50 0.535 vs 0.533 ms, p99 1.152 vs 1.158 ms - within the sub-bucket resolution. POC-patch attached, any feedback would be appreciated! -- Best regards, Roman Khapov
0001-pgbench-add-latency-percentiles-option.patch
Description: Binary data
