pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Mark Mielke <mark@mark.mielke.cc>
To: Scott Marlowe <scott.marlowe@gmail.com>
Cc: Gregory Stark <stark@enterprisedb.com>
Cc: Luke Lonergan <llonergan@greenplum.com>
Cc: Carlo Stonebanks <stonec.register@sympatico.ca>
Cc: pgsql-performance@postgresql.org
Subject: Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
Date: Mon, 10 Sep 2007 18:22:06 -0400
Message-ID: <46E5C38E.8030806@mark.mielke.cc> (raw)
In-Reply-To: <dcc563d10709101459o11451c33y8cab7dcf1e00a93f@mail.gmail.com>
References: <C30AF4C7.4230B%llonergan@greenplum.com>
	<87y7fekxga.fsf@oxford.xeocode.com>
	<dcc563d10709101459o11451c33y8cab7dcf1e00a93f@mail.gmail.com>

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>

view thread (27+ messages)  latest in thread

Message-ID: <46E5C38E.8030806@mark.mielke.cc>
Permalink:  ../46E5C38E.8030806@mark.mielke.cc/
Also on:    postgresql.org/message-id/46E5C38E.8030806@mark.mielke.cc

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: mark@mark.mielke.cc, scott.marlowe@gmail.com, stark@enterprisedb.com, llonergan@greenplum.com, stonec.register@sympatico.ca
  Subject: Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  In-Reply-To: <46E5C38E.8030806@mark.mielke.cc>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox