From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marcin Giedz <marcin(dot)giedz(at)eulerhermes(dot)pl> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Xeon vs Opteron - tests and questions |
Date: | 2005-11-09 19:19:09 |
Message-ID: | 18347.1131563949@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Marcin Giedz <marcin(dot)giedz(at)eulerhermes(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Maldonado | 2005-11-09 19:34:51 | Re: autovacuum daemon question... |
Previous Message | Marcin Giedz | 2005-11-09 18:49:23 | Re: Xeon vs Opteron - tests and questions |