> Well, my concern here is that it's *not* going to be simple. By the > time we get done adding enough switches to control connection to N > different hosts (possibly with different usernames, passwords, etc), > then adding frammishes to control which scripts get sent to which hosts, > and so on, I don't think it's really going to be simpler to use than > launching N copies of pgbench. > > It might be worth doing if we had features that allowed the different > test scripts to interact, so that they could do things like check > replication propagation from one host to another. But pgbench hasn't > got that, and in multi-job mode really can't have that (at least not > in the Unix separate-processes implementation). Anyway that's a whole > nother level of complexity that would have to be added on before you > got to a useful feature.
I do not intended to implement such a feature. As I wrote in the subject line, I intended to enhance pgbench for "multi-master" configuration. IMO, any node on multi-master configuration should accept *any* queries, not only read queries but write queries. So bare PostgreSQL streaming replication configuration cannot be a multi-master configuration and will not be a target of the new pgbench. -- 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
