Received: from localhost (maia-1.hub.org [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 5F6A79F9398
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 12 Dec 2006 11:48:02 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024)
	with ESMTP id 96802-10 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 12 Dec 2006 11:47:46 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id DB2119F9357
	for <pgsql-performance@postgresql.org>;
	Tue, 12 Dec 2006 11:47:46 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id kBCFlg45003357;
	Tue, 12 Dec 2006 10:47:42 -0500 (EST)
To: Alexander Staubo <alex@purefiction.net>
cc: Michael Stone <mstone+postgres@mathom.us>,
 pgsql-performance@postgresql.org
Subject: Re: New to PostgreSQL, performance considerations 
In-reply-to: <42B14BCF-B745-4F94-B5EA-97997744A4D5@purefiction.net> 
References: <8a0c7af10612110531sbb019ck259fb16d131fdb50@mail.gmail.com>
	<60psaq5t94.fsf@dba2.int.libertyrms.com>
	<E1GtolA-0008Fk-4R@elasmtp-banded.atl.sa.earthlink.net>
	<20061211173105.GH16692@mathom.us>
	<E1Gtplp-0004Ka-GM@elasmtp-junco.atl.sa.earthlink.net>
	<20061211184726.GI16692@mathom.us>
	<E1GtrB8-0005rw-Iu@elasmtp-kukur.atl.sa.earthlink.net>
	<457DA782.3060506@modgraph-usa.com>
	<8a0c7af10612111422x6bdcc0c2p7cbfeb5a7b0e0374@mail.gmail.com>
	<2FC0D8E7-F8ED-452F-BB13-FB665B516E7F@purefiction.net>
	<20061212123252.GR16692@mathom.us>
	<42B14BCF-B745-4F94-B5EA-97997744A4D5@purefiction.net>
Comments: In-reply-to Alexander Staubo <alex@purefiction.net>
	message dated "Tue, 12 Dec 2006 15:32:03 +0100"
Date: Tue, 12 Dec 2006 10:47:42 -0500
Message-ID: <3356.1165938462@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200612/295
X-Sequence-Number: 22351

Alexander Staubo <alex@purefiction.net> writes:
> No, fsync=on. The tps values are similarly unstable with fsync=off,  
> though -- I'm seeing bursts of high tps values followed by low-tps  
> valleys, a kind of staccato flow indicative of a write caching being  
> filled up and flushed.

It's notoriously hard to get repeatable numbers out of pgbench :-(

A couple of tips:
	* don't put any faith in short runs.  I usually use -t 1000
	  plus -c whatever.
	* make sure you loaded the database (pgbench -i) with a scale
	  factor (-s) at least equal to the maximum -c you want to test.
	  Otherwise you're mostly measuring update contention.
	* pay attention to when checkpoints occur.  You probably need
	  to increase checkpoint_segments if you want pgbench not to be
	  checkpoint-bound.

			regards, tom lane