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