Bruce Momjian wrote:
>>well, I usually get results that differ by that much from run to run.
>>Probably you ran in to more checkpoints on the second test.
>>Also, did you reinitialize the bench database with pgbench -i ?
>I destroyed the database and recreated it.
The only way I managed to control the variability in Pgbench was to
*reboot the machine* and recreate the database for each test. In
addition it seems that using a larger scale factor (e.g 200) helped as well.
Having said that, on FreeBSD 5.3 with hw.ata.wc=0 (i.e no write cache)
my results for s=200, t=10000 and c=4 were 49 (+/- 0.5) tps for both
7.4.6 and 8.0.0RC1 - no measurable difference. If I reduced the number
of transactions to t=1000, then 7.4.6 jumped ahead by about 10 tps.
Bruce - are you able to try s=200? It would be interesting to see what
your setup does.
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2004-12-29 03:12:56|
|Subject: Re: race condition for drop schema cascade?|
|Previous:||From: Tom Lane||Date: 2004-12-28 22:36:35|
|Subject: Re: buildfarm NetBSD/m68k tsearch regression failure |
pgsql-patches by date
|Next:||From: Mark Kirkwood||Date: 2004-12-29 03:03:24|
|Subject: Another Plpgsql trigger example - summary table|
|Previous:||From: Bruce Momjian||Date: 2004-12-28 22:07:12|
|Subject: Re: Bgwriter behavior|