Marcin Giedz <marcin.giedz@eulerhermes.pl> writes:
> I made some test comparing postgresql 8.0.4 based on two servers.
> Here is a link:
> http://85.128.68.44/
This is pretty nearly an ideal example of how NOT to use pg_bench :-(
In the first place, don't use a number of clients (-c) much exceeding
the scale factor (-s). If you do, then almost all you are measuring is
the effects of update contention. There are only scale-factor rows in
the branches table, and every pgbench transaction wants to update one of
the branches rows, so with -c 100 and -s 20 there are on average going
to be 5 transactions simultaneously trying to modify the same branches
row. 4 of them are going to be waiting. Does that really correspond
to a real-world situation that you want to optimize?
In the second place, you need a run length considerably longer than
-t 100 to avoid getting swamped by noise of startup/shutdown overhead.
I usually use at least -t 1000 if I want repeatable numbers.
BTW, PG 8.1 will probably do better than 8.0 on multi-CPU hardware.
regards, tom lane
