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's no multiple COMMIT in your senario-s due to
> > their lock conflicts.
>
> Hmm. It looks like using a 'scaling factor' larger than 1 is necessary
> to spread out the updates of "branches". AFAIR, the people who reported
> runs with scaling factors > 1 got pretty much the same results though.
>
People seem to believe your results are decisive
and would raise your results if the evidence is
required.
All clients of pgbench execute the same sequence
of queries. There could be various conflicts e.g.
oridinary lock, buffer lock, IO spinlock ...
I've been suspicious if pgbench is an (unique)
appropiriate test case for evaluaing commit_delay.
Regards,
Hiroshi Inoue
- RE: [ADMIN] v7.1b4 bad performance Schmidt, Peter
- Re: [ADMIN] v7.1b4 bad performance Tom Lane
- Re: [ADMIN] v7.1b4 bad performance Bruce Momjian
- Re: [ADMIN] v7.1b4 bad performance Bruce Momjian
- RE: [ADMIN] v7.1b4 bad performance Schmidt, Peter
- Re: [ADMIN] v7.1b4 bad performance Bruce Momjian
- Re: [HACKERS] Re: [ADMIN] v7.1b4 bad performance Tatsuo Ishii
- Re: [ADMIN] v7.1b4 bad performance Thomas Lockhart
- Re: [ADMIN] v7.1b4 bad performance Tatsuo Ishii
- Re: [HACKERS] Re: [ADMIN] v7.1b4 bad performance Hiroshi Inoue
- Re: [HACKERS] Re: [ADMIN] v7.1b4 bad performanc... Hiroshi Inoue
- Re: [HACKERS] Re: [ADMIN] v7.1b4 bad perfor... Hiroshi Inoue
- RE: [ADMIN] v7.1b4 bad performance Schmidt, Peter
- RE: [ADMIN] v7.1b4 bad performance The Hermit Hacker
- RE: [ADMIN] v7.1b4 bad performance Schmidt, Peter
- RE: [ADMIN] v7.1b4 bad performance Michael Ansley
- RE: [ADMIN] v7.1b4 bad performance Michael Ansley
- Re: [ADMIN] v7.1b4 bad performance Tom Lane
- Re: [ADMIN] v7.1b4 bad performance M Carling
- RE: [ADMIN] v7.1b4 bad performance Michael Ansley
- Re: [ADMIN] v7.1b4 bad performance Dmitry Morozovsky