Marcin Giedz <marcin.giedz@xxxxxxxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
