Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id EAB279FA084
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 10 Sep 2007 19:22:11 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 84961-02 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 10 Sep 2007 19:22:09 -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 8249F9F9D04
	for <pgsql-performance@postgresql.org>;
	Mon, 10 Sep 2007 19:22:08 -0300 (ADT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAGhg5UbO+Igp/2dsb2JhbACCQTWILA
X-IronPort-AV: E=Sophos;i="4.20,233,1186372800"; d="scan'208,217";a="6206393"
Received: from smtp.pppoe.ca ([65.39.196.238])
	by ironport2-out.pppoe.ca with ESMTP; 10 Sep 2007 18:22:07 -0400
Received: from [206.248.136.41] ([206.248.136.41])
	by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id PFG39407;
	Mon, 10 Sep 2007 18:22:07 -0400
Message-ID: <46E5C38E.8030806@mark.mielke.cc>
Date: Mon, 10 Sep 2007 18:22:06 -0400
From: Mark Mielke <mark@mark.mielke.cc>
User-Agent: Thunderbird 2.0.0.5 (X11/20070719)
MIME-Version: 1.0
To: Scott Marlowe <scott.marlowe@gmail.com>
CC: Gregory Stark <stark@enterprisedb.com>,
	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>
	<dcc563d10709101459o11451c33y8cab7dcf1e00a93f@mail.gmail.com>
In-Reply-To: <dcc563d10709101459o11451c33y8cab7dcf1e00a93f@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------000809090901020801070505"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/166
X-Sequence-Number: 26711

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

Scott Marlowe wrote:
> On 9/10/07, Gregory Stark <stark@enterprisedb.com> wrote:
>   
>> "Luke Lonergan" <llonergan@greenplum.com> writes:
>>     
>>> Should be a lot higher, something like 10-15 is approximating accurate.
>>>       
>> Most people's experience is that due to Postgres underestimating the benefits
>> of caching lowering the random_page_cost is helpful.
>>     
> Quite often the real problem is that they have effective_cache_size
> too small, and they use random_page_cost to get the planner to switch
> to index scans on small tables.  With a large effective_cache_size and
> small to moderate table (i.e. it fits in memory pretty handily) the
> planner seems much better in the last few major releases about picking
> an index over a sequential scan
In my case, I set effective_cache_size to 25% of the RAM available to 
the system (256 Mbytes), for a database that was about 100 Mbytes or 
less. I found performance to increase when reducing random_page_cost 
from 4.0 to 3.0.

For a database that truly fits entirely in memory, I assume 
random_page_cost is closer to 1.0. The planner should know that there is 
no significant seek cost for RAM.

I will try to compare results tonight using 8.2. The last time I checked 
may have been 8.1. I am also curious to see what the current algorithm 
is with regard to effective_cache_size.

Cheers,
mark

-- 
Mark Mielke <mark@mielke.cc>


--------------000809090901020801070505
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">
Scott Marlowe wrote:
<blockquote
 cite="mid:dcc563d10709101459o11451c33y8cab7dcf1e00a93f@mail.gmail.com"
 type="cite">
  <pre wrap="">On 9/10/07, Gregory Stark <a class="moz-txt-link-rfc2396E" href="mailto:stark@enterprisedb.com">&lt;stark@enterprisedb.com&gt;</a> wrote:
  </pre>
  <blockquote 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="">Should be a lot higher, something like 10-15 is approximating accurate.
      </pre>
    </blockquote>
    <pre wrap="">Most people's experience is that due to Postgres underestimating the benefits
of caching lowering the random_page_cost is helpful.
    </pre>
  </blockquote>
  <pre wrap=""><!---->Quite often the real problem is that they have effective_cache_size
too small, and they use random_page_cost to get the planner to switch
to index scans on small tables.  With a large effective_cache_size and
small to moderate table (i.e. it fits in memory pretty handily) the
planner seems much better in the last few major releases about picking
an index over a sequential scan</pre>
</blockquote>
In my case, I set effective_cache_size to 25% of the RAM available to
the system (256 Mbytes), for a database that was about 100 Mbytes or
less. I found performance to increase when reducing random_page_cost
from 4.0 to 3.0.<br>
<br>
For a database that truly fits entirely in memory, I assume
random_page_cost is closer to 1.0. The planner should know that there
is no significant seek cost for RAM.<br>
<br>
I will try to compare results tonight using 8.2. The last time I
checked may have been 8.1. I am also curious to see what the current
algorithm is with regard to effective_cache_size.<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>

--------------000809090901020801070505--