From: John A Meinel <john@arbash-meinel.com>
To: emil@baymountain.com
Cc: pgsql-performance@postgresql.org
Subject: Re: Planner constants for RAM resident databases
Date: Fri, 01 Jul 2005 21:40:49 -0500
Message-ID: <42C5FEB1.6090601@arbash-meinel.com> (raw)
In-Reply-To: <200507012159.39041.emil@baymountain.com>
References: <200507012159.39041.emil@baymountain.com>
Emil Briggs wrote:
>I'm working with an application where the database is entirely resident in RAM
>(the server is a quad opteron with 16GBytes of memory). It's a web
>application and handles a high volume of queries. The planner seems to be
>generating poor plans for some of our queries which I can fix by raising
>cpu_tuple_cost. I have seen some other comments in the archives saying that
>this is a bad idea but is that necessarily the case when the database is
>entirely resident in RAM?
>
>Emil
>
>
>
Generally, the key knob to twiddle when everything fits in RAM is
random_page_cost. If you truly have everything in RAM you could set it
almost to 1. 1 means that it costs exactly the same to go randomly
through the data then it does to go sequential. I would guess that even
in RAM it is faster to go sequential (since you still have to page and
deal with L1/L2/L3 cache, etc). But the default random_page_cost of 4 is
probably too high for you.
John
=:->
Attachments:
signature.asc (application/pgp-signature, 252B) download
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: john@arbash-meinel.com, emil@baymountain.com
Subject: Re: Planner constants for RAM resident databases
In-Reply-To: <42C5FEB1.6090601@arbash-meinel.com>
* 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