From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: reducing random_page_cost from 4 to 2 to force index scan |
Date: | 2011-05-16 01:05:25 |
Message-ID: | 4DD07855.8080907@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 16/05/11 05:45, Cédric Villemain wrote:
> 2011/5/15 Josh Berkus <josh(at)agliodbs(dot)com>:
>> disk pages might be in cache.
>> However, I think that's beyond feasibility for current software/OSes.
>
> maybe not :) mincore is available in many OSes, and windows have
> options to get those stats too.
AFAIK, mincore() is only useful for mmap()ed files and for finding out
if it's safe to access certain blocks of memory w/o risking triggering
heavy swapping.
It doesn't provide any visibility into the OS's block device / file
system caches; you can't ask it "how much of this file is cached in RAM"
or "is this range of blocks in this file cached in RAM".
Even if you could, it's hard to see how an approach that relied on
asking the OS through system calls about the cache state when planning
every query could be fast enough to be viable.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2011-05-16 01:18:06 | Re: reducing random_page_cost from 4 to 2 to force index scan |
Previous Message | Craig Ringer | 2011-05-16 00:25:23 | Re: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation) |