Re: reducing random_page_cost from 4 to 2 to force index scan - Mailing list pgsql-performance

From Craig Ringer
Subject Re: reducing random_page_cost from 4 to 2 to force index scan
Date
Msg-id 4DD07855.8080907@postnewspapers.com.au
Whole thread Raw
In response to Re: reducing random_page_cost from 4 to 2 to force index scan  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
Responses Re: reducing random_page_cost from 4 to 2 to force index scan  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-performance
On 16/05/11 05:45, Cédric Villemain wrote:
> 2011/5/15 Josh Berkus <josh@agliodbs.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

pgsql-performance by date:

Previous
From: Craig Ringer
Date:
Subject: Re: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
Next
From: Greg Smith
Date:
Subject: Re: reducing random_page_cost from 4 to 2 to force index scan