Re: Xeon vs Opteron - tests and questions

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

In response to

Responses

Browse pgsql-admin by date

  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