From: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Warm-up cache may have its virtue |
Date: | 2006-01-07 19:58:23 |
Message-ID: | dpp6em$p25$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Greg Stark" <gsstark(at)mit(dot)edu> wrote in message
news:87ek3k2c9j(dot)fsf(at)stark(dot)xeocode(dot)com(dot)(dot)(dot)
>
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-07 20:08:37 | Re: catalog corruption bug |
Previous Message | Jeremy Drake | 2006-01-07 19:27:17 | Re: catalog corruption bug |