Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id E1DD59F9FE3
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 10 Sep 2007 19:08:33 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 44212-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 10 Sep 2007 19:08:23 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from ironport2-out.pppoe.ca (ironport2-out.pppoe.ca
	[206.248.154.182])
	by postgresql.org (Postfix) with ESMTP id E00249FA0F7
	for <pgsql-performance@postgresql.org>;
	Mon, 10 Sep 2007 19:08:28 -0300 (ADT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAB9d5UbO+Igp/2dsb2JhbACCQTWILA
X-IronPort-AV: E=Sophos;i="4.20,233,1186372800"; d="scan'208,217";a="6205935"
Received: from smtp.pppoe.ca ([65.39.196.238])
	by ironport2-out.pppoe.ca with ESMTP; 10 Sep 2007 18:08:27 -0400
Received: from [206.248.136.41] ([206.248.136.41])
	by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id PFS28527;
	Mon, 10 Sep 2007 18:08:27 -0400
Message-ID: <46E5C05A.7010800@mark.mielke.cc>
Date: Mon, 10 Sep 2007 18:08:26 -0400
From: Mark Mielke <mark@mark.mielke.cc>
User-Agent: Thunderbird 2.0.0.5 (X11/20070719)
MIME-Version: 1.0
To: Gregory Stark <stark@enterprisedb.com>
CC: Luke Lonergan <llonergan@greenplum.com>,
	Carlo Stonebanks <stonec.register@sympatico.ca>,
	pgsql-performance@postgresql.org
Subject: Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
References: <C30AF4C7.4230B%llonergan@greenplum.com>
	<87y7fekxga.fsf@oxford.xeocode.com>
In-Reply-To: <87y7fekxga.fsf@oxford.xeocode.com>
Content-Type: multipart/alternative;
	boundary="------------010903070602060302070401"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/165
X-Sequence-Number: 26710

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

Gregory Stark wrote:
> "Luke Lonergan" <llonergan@greenplum.com> writes:
>   
>> Increasing the number of disks in a RAID actually makes the number higher,
>> not lower.  Until Postgres gets AIO + the ability to post multiple
>> concurrent IOs on index probes, random IO does not scale with increasing
>> disk count, but sequential does, thus the increasing "random page cost" as
>> the RAID gets faster.
>>     
> What I don't understand is the bit about "until Postgres gets AIO + the
> ability to post multiple concurrent IOs on index probes". Even with AIO your
> seek times are not going to be improved by wide raid stripes. And you can't
> possibly find the page at level n+1 before you've looked at the page at level
> n. Do you mean to be able to probe multiple index keys simultaneously? How
> does that work out
One suggestion: The plan is already in a tree. With some dependency 
analysis, I assume the tree could be executed in parallel (multiple 
threads or event triggered entry into a state machine), and I/O to fetch 
index pages or table pages could be scheduled in parallel. At this 
point, AIO becomes necessary to let the underlying system (and hardware 
with tagged queueing?) schedule which pages should be served best first.

Cheers,
mark

-- 
Mark Mielke <mark@mielke.cc>


--------------010903070602060302070401
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">
Gregory Stark wrote:
<blockquote cite="mid:87y7fekxga.fsf@oxford.xeocode.com" type="cite">
  <pre wrap="">"Luke Lonergan" <a class="moz-txt-link-rfc2396E" href="mailto:llonergan@greenplum.com">&lt;llonergan@greenplum.com&gt;</a> writes:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Increasing the number of disks in a RAID actually makes the number higher,
not lower.  Until Postgres gets AIO + the ability to post multiple
concurrent IOs on index probes, random IO does not scale with increasing
disk count, but sequential does, thus the increasing "random page cost" as
the RAID gets faster.
    </pre>
  </blockquote>
  <pre wrap=""><!---->What I don't understand is the bit about "until Postgres gets AIO + the
ability to post multiple concurrent IOs on index probes". Even with AIO your
seek times are not going to be improved by wide raid stripes. And you can't
possibly find the page at level n+1 before you've looked at the page at level
n. Do you mean to be able to probe multiple index keys simultaneously? How
does that work out</pre>
</blockquote>
One suggestion: The plan is already in a tree. With some dependency
analysis, I assume the tree could be executed in parallel (multiple
threads or event triggered entry into a state machine), and I/O to
fetch index pages or table pages could be scheduled in parallel. At
this point, AIO becomes necessary to let the underlying system (and
hardware with tagged queueing?) schedule which pages should be served
best first.<br>
<br>
Cheers,<br>
mark<br>
<br>
<pre class="moz-signature" cols="72">-- 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc">&lt;mark@mielke.cc&gt;</a>
</pre>
</body>
</html>

--------------010903070602060302070401--