X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id D93999DCAB3
	for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
	Tue, 29 Nov 2005 00:34:12 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 07329-01
	for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
	Tue, 29 Nov 2005 00:34:10 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from toad.mtbrook.bozemanpass.com (toad.mtbrook.bozemanpass.com
	[69.145.82.195])
	by postgresql.org (Postfix) with ESMTP id CC3CF9DCAC2
	for <pgsql-hackers@postgresql.org>;
	Tue, 29 Nov 2005 00:34:09 -0400 (AST)
Received: from [69.145.82.218] (unknown [69.145.82.218])
	by toad.mtbrook.bozemanpass.com (Postfix) with ESMTP id 4507F11027B
	for <pgsql-hackers@postgresql.org>;
	Mon, 28 Nov 2005 20:34:09 -0800 (PST)
Message-ID: <438BDA52.7090601@boreham.org>
Date: Mon, 28 Nov 2005 21:34:26 -0700
From: David Boreham <david_list@boreham.org>
Reply-To: david_list@boreham.org
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: ice-broker scan thread
References: <Pine.LNX.4.58.0511282217470.13586@josh.db>
	<Pine.LNX.4.58.0511291429330.18112@linuxworld.com.au>
	<438BD493.3070507@boreham.org>
	<Pine.LNX.4.58.0511291513260.18370@linuxworld.com.au>
In-Reply-To: <Pine.LNX.4.58.0511291513260.18370@linuxworld.com.au>
Content-Type: multipart/alternative;
	boundary="------------040008020406010805090100"
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.001 required=5 tests=[AWL=-0.000,
	HTML_MESSAGE=0.001]
X-Spam-Score: 0.001
X-Spam-Level: 
X-Archive-Number: 200511/1455
X-Sequence-Number: 76737

This is a multi-part message in MIME format.
--------------040008020406010805090100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>
>The paper I linked to seemed to suggest that they weren't using async IO
>in 9.2 -- which is fairly old. I'm not sure why the authors didn't test
>10g.
>  
>
...<reads paper>... ok, interesting. Did they say that Oracle isn't 
using aio ?
I can't see that. They that Oracle has no more than one outstanding I/O
operation in flight per concurrent query,
and they appear to think that's a bad thing. I'm not seeing
that myself. Perhaps once I sleep on it, it'll become clear what they're 
getting at.

One theory for lack of aio in Oracle as tested in that paper would be 
that they
were testing on Linux. Since aio is relatively new in Linux I wouldn't 
be surprised
if Oracle didn't actually use it until it's known to be widely deployed 
in the field
and to have proven reliability. Perhaps we've reached that state around now,
and so Oracle may not yet have released an aio-capable Linux version of 
their
RDBMS. Just a theory...someone from those tubular towers lurking here
could tell us for sure I guess...





--------------040008020406010805090100
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote
 cite="midPine.LNX.4.58.0511291513260.18370@linuxworld.com.au"
 type="cite">
  <pre wrap=""><!---->
The paper I linked to seemed to suggest that they weren't using async IO
in 9.2 -- which is fairly old. I'm not sure why the authors didn't test
10g.
  </pre>
</blockquote>
...&lt;reads paper&gt;... ok, interesting. Did they say that Oracle
isn't using aio ?<br>
I can't see that. They that Oracle has no more than one outstanding I/O
<br>
operation in flight per concurrent query, <br>
and they appear to think that's a bad thing. I'm not seeing<br>
that myself. Perhaps once I sleep on it, it'll become clear what
they're getting at.<br>
<br>
One theory for lack of aio in Oracle as tested in that paper would be
that they<br>
were testing on Linux. Since aio is relatively new in Linux I wouldn't
be surprised<br>
if Oracle didn't actually use it until it's known to be widely deployed
in the field<br>
and to have proven reliability. Perhaps we've reached that state around
now,<br>
and so Oracle may not yet have released an aio-capable Linux version of
their<br>
RDBMS. Just a theory...someone from those tubular towers lurking here<br>
could tell us for sure I guess...<br>
<br>
<br>
<br>
<br>
</body>
</html>

--------------040008020406010805090100--