| 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-22 01:51:14 |
| Message-ID: | 1399.1345600274@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
>> 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.
> 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.
Well, you're being shortsighted then, because such a feature will barely
have hit the git repository before somebody wants to use it differently.
I can easily imagine wanting to stress a master plus some hot-standby
slaves, for instance; and that would absolutely require being able to
direct different subsets of the test scripts to different hosts.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2012-08-22 02:02:56 | Re: multi-master pgbench? |
| Previous Message | Tom Lane | 2012-08-22 01:47:13 | Re: problem when optimizing the window aggregation |