Re: [HACKERS] Re: v7.1b4 bad performance

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: hannu(at)tm(dot)ee, pgsql-hackers(at)postgresql(dot)org, pgsql-admin(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: v7.1b4 bad performance
Date: 2001-02-24 02:38:13
Message-ID: 20010224113813L.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

> Okay, plan B then: let's ask people to redo their benchmarks with
> -s bigger than one. Now, how much bigger?
>
> To the extent that you think this is a model of a real bank, it should
> be obvious that the number of concurrent transactions cannot exceed the
> number of tellers; there should never be any write contention on a
> teller's table row, because only that teller (client) should be issuing
> transactions against it. Contention on a branch's row is realistic,
> but not from more clients than there are tellers in the branch.
>
> As a rule of thumb, then, we could say that the benchmark's results are
> not to be believed for numbers of clients exceeding perhaps 5 times the
> scale factor, ie, half the number of teller rows (so that it's not too
> likely we will have contention on a teller row).

At least -s 5 seems reasonable for me too. Maybe we should make it as
the default setting for pgbench?
--
Tatsuo Ishii

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Stephan Szabo 2001-02-24 07:21:19 Re: relation does not exist
Previous Message Dave Page 2001-02-23 22:48:31 RE: select * from pgadmin_users; causes error

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-02-24 03:10:38 WAL does not recover gracefully from out-of-disk-space
Previous Message Bruce Momjian 2001-02-24 02:31:12 Re: CommitDelay performance improvement