> Why wouldn't you just fire up several copies of pgbench, one per host?
Well, more convenient. Aside from bottle neck discussion below, simple
tool to generate load is important IMO. It will help developers to
enhance multi-master configuration in finding bugs and problems if
any. IMO I saw similar relationship between pgbench and PostgreSQL.
> The main reason I'm dubious about this is that it's demonstrable that
> pgbench itself is the bottleneck in many test scenarios. That problem
> gets worse the more backends you try to have it control. You can of
> course "solve" this with multiple threads in pgbench, but as soon as you
> do that there's no functional benefit over just running several copies.
Are you sure that running several copies of pgbench could produce more
TPS than single pgbench? I thought that's just a limitation of the
resource of the machine which pgbench is running on. So I thought to
avoid the bottle neck of pgbench, I have to use several pgbench client
machines simultaneously anyway.
Another point is, what kind of transactions you want. "pgbench -S"
type transaction produces trivial load, and could easily reveal bottle
neck of pgbench. However this type of transaction is pretty extrem one
and very different from transactions in the real world. So even if
your argument is true, I guess it's only adopted to "pgbench -S" case.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
