Re: reducing random_page_cost from 4 to 2 to force index scan
От | Craig Ringer |
---|---|
Тема | Re: reducing random_page_cost from 4 to 2 to force index scan |
Дата | |
Msg-id | 4DD07855.8080907@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: reducing random_page_cost from 4 to 2 to force index scan (Cédric Villemain <cedric.villemain.debian@gmail.com>) |
Ответы |
Re: reducing random_page_cost from 4 to 2 to force index
scan
|
Список | 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 по дате отправления: