Re: Warm-up cache may have its virtue

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

In response to

Browse pgsql-hackers by date

  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