Re: [HACKERS] Re: v7.1b4 bad performance - Mailing list pgsql-admin

From Tom Lane
Subject Re: [HACKERS] Re: v7.1b4 bad performance
Date
Msg-id 28371.982946542@sss.pgh.pa.us
Whole thread Raw
In response to Re: v7.1b4 bad performance  (Dmitry Morozovsky <marck@rinet.ru>)
Responses Re: [HACKERS] Re: v7.1b4 bad performance  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-admin
Tatsuo Ishii <t-ishii@sra.co.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

pgsql-admin by date:

Previous
From: Paul Huppe
Date:
Subject: Re: v7.0.3 Regress Tests Errors
Next
From: Tom Lane
Date:
Subject: Re: v7.0.3 Regress Tests Errors