| From: | Mark Kirkwood <markir(at)coretech(dot)co(dot)nz> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | John Hansen <john(at)geeknet(dot)com(dot)au>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Bgwriter behavior |
| Date: | 2004-12-28 23:20:25 |
| Message-ID: | 41D1EA39.4040105@coretech.co.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
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.
regards
Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2004-12-29 03:12:56 | Re: race condition for drop schema cascade? |
| Previous Message | Tom Lane | 2004-12-28 22:36:35 | Re: buildfarm NetBSD/m68k tsearch regression failure |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kirkwood | 2004-12-29 03:03:24 | Another Plpgsql trigger example - summary table |
| Previous Message | Bruce Momjian | 2004-12-28 22:07:12 | Re: Bgwriter behavior |