Gabriela Serventi <gabrielaserventi@hotmail.com> writes:
> $ pgbench -l -c 100 -T 30 pgbench
> starting vacuum...end.
> transaction type: <builtin: TPC-B (sort of)>
> scaling factor: 1
> query mode: simple
> number of clients: 100
> number of threads: 1
> duration: 30 s
> number of transactions actually processed: 27428
> latency average = 110.104 ms
> tps = 908.234296 (including connections establishing)
> tps = 908.278187 (excluding connections establishing)
That's not a tremendously exciting benchmark case, for a number of
reasons:
* 100 sessions in a scale-factor-1 database are all going to be fighting
over updating the single row in the pgbench_branches table.
* 100 sessions driven by a single pgbench thread are probably going to be
bottlenecked by that thread, not by the server.
* 100 sessions on a machine with only 2 cores is going to be all about
process-swap contention anyhow.
My first thought about why the difference from 8.4 to 9.6 is that pgbench
has grown a lot more measurement apparatus since then (for example, the
transaction latency numbers, which weren't there at all in 8.4). You
might try testing 9.6 server with 8.4 pgbench and vice versa to tease out
how much of this is actually on pgbench changes not the server. But in
the end, what you're measuring here is mostly contention, and you'd need
to alter the test parameters to make it not so. The "Good Practices"
section at the bottom of the pgbench reference page has some tips about
that.
regards, tom lane