| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: multi-master pgbench? |
| Date: | 2012-08-22 00:41:22 |
| Message-ID: | 20120822.094122.436058782286594607.t-ishii@sraoss.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Wang, Chaoyong | 2012-08-22 01:12:06 | problem when optimizing the window aggregation |
| Previous Message | David Fetter | 2012-08-22 00:33:56 | Re: multi-master pgbench? |