Subject: Re: Read/Write block sizes
From: "Jeffrey W. Baker" <jwbaker@acm.org>
To: Guy Thornley <guy@esphion.com>
Cc: Josh Berkus <josh@agliodbs.com>,
	pgsql-performance@postgresql.org, Steve Poe <spoe@sfnet.cc>,
	Chris Browne <cbbrowne@acm.org>
In-Reply-To: <20050824052023.GB31806@conker.esphion.com>
References: <d4b67d7c2b.d7c2bd4b67@bur-mail1.east.sun.com>
	<60k6icpapm.fsf@dba2.int.libertyrms.com>
	<1124846743.12045.94.camel@amd64-laptop-spoe>
	<200508231931.29682.josh@agliodbs.com>
	<1124852854.11147.5.camel@noodles>
	<20050824052023.GB31806@conker.esphion.com>
Content-Type: text/plain
Date: Tue, 23 Aug 2005 22:25:21 -0700
Message-Id: <1124861121.11270.1.camel@noodles>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Wed, 2005-08-24 at 17:20 +1200, Guy Thornley wrote:
> As for the async IO, sure you might think 'oh async IO would be so cool!!'
> and I did, once, too. But then I sat down and _thought_ about it, and
> decided well, no, actually, theres _very_ few areas it could actually help,
> and in most cases it just make it easier to drive your box into lseek()
> induced IO collapse.
> 
> Dont forget that already in postgres, you have a process per connection, and
> all the processes take care of their own I/O.

That's the problem.  Instead you want 1 or 4 or 10 i/o slaves
coordinating the I/O of all the backends optimally.  For instance, with
synchronous scanning.

-jwb