bench -i inoue2
.
pgbench -i inoue10
3) invoke a modified pgbench
pgbench -c 10 -t 100 inoue
I've attached a patch to change pgbench so that
each connection connects to different database
whose name is 'xxxx%d'( is th
nch" isn't a pgbench any more and I didn't intend
to change pgbench's spec like that. Probably it was my mistake
that I had posted my test cases using the form of patch. My
intension was to clarify the difference of my test cases.
However heavy conflicts with scaling factor 1 doesn't seem
preferable at least as the default of pgbench.
Regards,
Hiroshi Inoue
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> >> Hmm, you mean you set up a separate test database for each pgbench
> >> "client", but all under the same postmaster?
>
> > Yes. Different database is to make the confl
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I changed pgbench so that different connection connects
> > to the different database and got the following results.
>
> Hmm, you mean
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > In your test cases I always see "where bid = 1" at "update branches"
> > i.e.
> > update branches set bbalance = bbalance + ... where bid = 1
>
> > ISTM there&#
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I've been suspicious if pgbench is an (unique)
> > appropiriate test case for evaluaing commit_delay.
>
> Of course it isn't. Never trust only one benchmark.
>
> I've asked
uot;where bid = 1" at "update branches"
i.e.
update branches set bbalance = bbalance + ... where bid = 1
ISTM there's no multiple COMMIT in your senario-s due to
their lock conflicts.
Regards,
Hiroshi Inoue
