"Greg Stark" <gsstark@mit.edu> wrote in message
news:87ek3k2c9j.fsf@stark.xeocode.com...
>
> Hm. Personally I have a hunch you're right. But there we have no actual
> evidence. The first thing that needs to happen is changes to use O_DIRECT
> for
> everything and then benchmarking one of those big TPC tests with the
> O_DIRECT
> build and a large buffer cache versus a normal build with an traditional
> buffer cache size.
>
A nice thing is that we can have both. User can choose to use small
shared_buffer or big shared_buffer. According to user's choice, we will use
different IO/buffering strategy.
> If it's anywhere close, even with no prefetching then it ought to be clear
> that the costs of double buffering are becoming substantial.
>
AFAIU double buffering only hurts when we use big shared_buffer value.
> As far as predicting cache hits I think the best Postgres could do is
> track
> the average cache hit rate, either overall for the whole system or perhaps
> even per table and index.
>
There is a linux kernel implementation of pre-read:
http://glide.stanford.edu/lxr/source/mm/readahead.c?v=linux-2.6.5#L306
We have better hints for it: seqscan and bitmap scan.
Regards,
Qingqing