Re: reducing random_page_cost from 4 to 2 to force index scan

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

In response to

Responses

Browse pgsql-performance by date

  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)