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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
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-23 16:42:22
Message-ID: 28371.982946542@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
>> It seems to me that the branches table should have at least 10 to 100
>> entries, and tellers about 10 times whatever branches is. 100000
>> accounts rows seems enough though.

> Those numbers are defined in the TPC-B spec.

Ah. And of course, the TPC bunch never thought anyone would be
interested in the results with scale factors so tiny as one ;-),
so they didn't see any problem with it.

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).

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2001-02-23 16:55:32 Re: v7.0.3 Regress Tests Errors
Previous Message Paul Huppe 2001-02-23 16:29:51 Re: v7.0.3 Regress Tests Errors

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Engdahl 2001-02-23 16:58:45 PostgreSQL JDBC
Previous Message Tom Lane 2001-02-23 16:32:21 CommitDelay performance improvement