Gabriela Serventi <gabrielaserventi@xxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
