Re: Warm-up cache may have its virtue
От | Qingqing Zhou |
---|---|
Тема | Re: Warm-up cache may have its virtue |
Дата | |
Msg-id | dpp6em$p25$1@news.hub.org обсуждение исходный текст |
Ответ на | Warm-up cache may have its virtue (Qingqing Zhou <zhouqq@cs.toronto.edu>) |
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: