Re: Performance Tuning Question - Mailing list pgsql-general

From Tom Lane
Subject Re: Performance Tuning Question
Date
Msg-id 13390.1031602758@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance Tuning Question  (Brian Hirt <bhirt@mobygames.com>)
List pgsql-general
Brian Hirt <bhirt@mobygames.com> writes:
> On Mon, 2002-09-09 at 03:21, Martijn van Oosterhout wrote:
>> On Sun, Sep 08, 2002 at 11:04:31PM -0600, Brian Hirt wrote:
> It seems the planner tries to avoid I/O so much that the default tuning
> parameters works against us a bit.  i've tried a few changes here and
> there, but without much luck since i don't really know what to change
> tho values to.
>>
>> Why is this a bad thing? The less IO the better, right?

> If there was actually IO going on, then yes I agree.

Yeah.  For a situation where the database is effectively 100% cached
in memory by the kernel, it'd be reasonable to set random_page_cost
to 1 (or maybe a little more depending on how much you believe the
"100% cached" approximation).  The actual cost of pulling a cached page
from kernel buffer to PG buffer should be the same whether the access
is sequential or not.  It's only when you have to physically go to the
disk that there's likely to be a penalty for random access.

Anyway, RANDOM_PAGE_COST is the thing to be tweaking.

            regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Creating tons of tables to support a query
Next
From: "Johnson, Shaunn"
Date:
Subject: Re: Load sharing question