Re: Performance Tuning Question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brian Hirt <bhirt(at)mobygames(dot)com>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: Performance Tuning Question
Date: 2002-09-09 20:19:18
Message-ID: 13390.1031602758@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Brian Hirt <bhirt(at)mobygames(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Johnson, Shaunn 2002-09-09 20:22:08 Re: Load sharing question
Previous Message Tom Lane 2002-09-09 20:10:29 Re: Creating tons of tables to support a query