From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: multi-master pgbench? |
Date: | 2012-08-21 23:25:34 |
Message-ID: | 28551.1345591534@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
>> 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.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Flower | 2012-08-21 23:34:36 | Re: Audit Logs WAS: temporal support patch |
Previous Message | Kevin Grittner | 2012-08-21 22:56:48 | Re: Audit Logs WAS: temporal support patch |