| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | greg(at)turnstep(dot)com |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: multi-master pgbench? |
| Date: | 2012-08-22 04:12:31 |
| Message-ID: | 20120822.131231.841132458032800876.t-ishii@sraoss.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> As the maintainer of software that does multi-master, I'm a little
> confused as to why we would extend pg_bench to do this. The software
> in question should be doing the testing itself, ideally via
> it's test suite (i.e. "make test"). Having pg_bench do any of this
> would be at best a very poor subset of the tests the software
> should be performing. I suppose if the software *uses* pg_bench for
> its tests already, once could argue a limited test case - but it seems
> difficult to design some pg_bench options generic and powerful enough
> to handle other cases outside of the one software this change is aimed at.
Well, my point was in upthread:
> Right. If pgbench could have such a functionarlity, we could compare
> those projects by using pgbench. Currently those projects use
> different benchmarking tools. That means, the comparison is something
> like apple-to-orange. With enhanced pgbench we could do apple-to-apple
> comparison.
--
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 | Peter Eisentraut | 2012-08-22 04:26:36 | Re: 64-bit API for large object |
| Previous Message | Greg Sabino Mullane | 2012-08-22 03:35:39 | Re: multi-master pgbench? |