"Greg Stark" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
