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