OS cached buffers (was: Support Parallel Query Execution in Executor) - Mailing list pgsql-hackers

From Jim C. Nasby
Subject OS cached buffers (was: Support Parallel Query Execution in Executor)
Date
Msg-id 20060411203858.GT49405@pervasive.com
Whole thread Raw
In response to Re: Support Parallel Query Execution in Executor  ("Luke Lonergan" <llonergan@greenplum.com>)
Responses Re: OS cached buffers (was: Support Parallel Query Execution  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Mon, Apr 10, 2006 at 12:02:56PM -0700, Luke Lonergan wrote:
> Hannu,
> 
> On 4/10/06 2:23 AM, "Hannu Krosing" <hannu@skype.net> wrote:
> 
> >> The cost of fetching a page from the OS is not really much of an
> >> overhead,
> > 
> > Have you tested this ?
> 
> I have - the overhead of fetching a page from Linux I/O cache to buffer
> cache is about an additional 20% over fetching it directly from buffer cache
> on PG 7.4.

Is there any pratcical way to tell the difference between a page comming
from the OS cache and one comming from disk? Or maybe for a set of pages
an estimate on how many came from cache vs disk? There's some areas
where having this information would be very useful, such as for vacuum
delay. It would make tuning much easier, and it would also give us some
insight on how heavily loaded disks were, which would also be useful
info for vacuum to have (so we could adjust vacuum_cost_delay
dynamically based on load).
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: plpgsql by default
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Support Parallel Query Execution in Executor