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 по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
Следующее
От: Greg Smith
Дата:
Сообщение: Re: reducing random_page_cost from 4 to 2 to force index scan