To: Josh Berkus <josh@agliodbs.com>
cc: pgsql-performance@postgresql.org,
	Alvaro Herrera <alvherre@commandprompt.com>
Subject: Re: User concurrency thresholding: where do I look? 
In-reply-to: <200707191819.13899.josh@agliodbs.com> 
References: <200707190828.59088.josh@agliodbs.com>
	<20070719173704.GA12084@alvh.no-ip.org>
	<14009.1184867115@sss.pgh.pa.us>
	<200707191819.13899.josh@agliodbs.com>
Comments: In-reply-to Josh Berkus <josh@agliodbs.com>
	message dated "Thu, 19 Jul 2007 18:19:13 -0700"
Date: Thu, 19 Jul 2007 21:45:26 -0400
Message-ID: <15685.1184895926@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Josh Berkus <josh@agliodbs.com> writes:
>> Josh, what sort of workload is being tested here --- read-mostly,
>> write-mostly, a mixture?

> It's a TPCC-like workload, so heavy single-row updates, and the 
> updates/inserts are what's being measured.  For that matter, when I've seen 
> this before it was with heavy-write workloads and we were measuring the 
> number of updates/inserts and not the number of reads.

Well, if the load is a lot of short writing transactions then you'd
expect the throughput to depend on how fast stuff can be pushed down to
WAL.  What have you got wal_buffers set to?  Are you using a commit
delay?  What's the I/O system anyway (any BB write cache on the WAL
disk?) and what wal sync method are you using?

While I'm asking questions, exactly what were the data columns you
presented?  Txn/User doesn't make much sense to me, and I'm not sure
what "response time" you were measuring either.

			regards, tom lane