Skip site navigation (1) Skip section navigation (2)

Re: Bgwriter behavior

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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.



In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2004-12-29 03:12:56
Subject: Re: race condition for drop schema cascade?
Previous:From: Tom LaneDate: 2004-12-28 22:36:35
Subject: Re: buildfarm NetBSD/m68k tsearch regression failure

pgsql-patches by date

Next:From: Mark KirkwoodDate: 2004-12-29 03:03:24
Subject: Another Plpgsql trigger example - summary table
Previous:From: Bruce MomjianDate: 2004-12-28 22:07:12
Subject: Re: Bgwriter behavior

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group