| 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: | Whole Thread | Raw Message | 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 |