OS cached buffers (was: Support Parallel Query Execution in Executor)
От | Jim C. Nasby |
---|---|
Тема | OS cached buffers (was: Support Parallel Query Execution in Executor) |
Дата | |
Msg-id | 20060411203858.GT49405@pervasive.com обсуждение исходный текст |
Ответ на | Re: Support Parallel Query Execution in Executor ("Luke Lonergan" <llonergan@greenplum.com>) |
Ответы |
Re: OS cached buffers (was: Support Parallel Query Execution
|
Список | 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 по дате отправления: