From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: Erik Jones <erik@myemma.com>
Subject: Re: Shared buffers, db transactions commited, and write IO on Solaris
Date: Fri, 30 Mar 2007 14:46:35 -0700
User-Agent: KMail/1.8
Cc: pgsql-performance@postgresql.org
References: <9B7F4B34-7E96-4501-BCE0-D0BED739530A@myemma.com>
	<200703291723.24061.josh@agliodbs.com>
	<39BA9EF6-4928-4128-B4BB-A8DE2C536053@myemma.com>
In-Reply-To: <39BA9EF6-4928-4128-B4BB-A8DE2C536053@myemma.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200703301446.35858.josh@agliodbs.com>

Erik,

> You'er welcome!  However, I believe our situation is very different
> from what you're testing if I understand you correctly.  Are you
> saying that you're entire database will fit in memory?  If so, then
> these are very different situations as there is no way ours could
> ever do that.  In fact, I'm not sure that forcedirectio would really
> net you any gain in that situation as the IO service time will be
> basically nil if the filesystem cache doesn't have to page which I
> would think is why your seeing what you are.

Even more interesting.  I guess we've been doing too much work with 
benchmark workloads, which tend to be smaller databases.  

Thing is, there's *always* I/O for a read/write database.  If nothing else, 
updates have to be synched to disk.

Anyway ... regarding the mystery transactions ... are you certain that it's 
not your application?  I can imagine that, if your app has a fairly tight 
retry interval for database non-response, that I/O sluggishness could 
result in commit attempts spinning out of control.

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco