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
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 |