Print latency percentiles in pgbench

From: Roman Khapov <rkhapov(at)yandex-team(dot)ru>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Print latency percentiles in pgbench
Date: 2026-10-31 06:54:32
Message-ID: A2F803DC-1F39-4783-8D62-63A204F17480@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
0001-pgbench-add-latency-percentiles-option.patch application/octet-stream 16.4 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhang Ziming 2026-10-31 06:56:46 RE: [PATCH] Restrict partial unique index estimates to base quals
Previous Message shihao zhong 2026-10-31 04:58:04 Re: improving handling of FPIs during recovery prefetching