Re: Warm-up cache may have its virtue

From: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Warm-up cache may have its virtue
Date: 2006-01-06 01:37:18
Message-ID: Pine.LNX.4.58.0601052026420.13793@eon.cs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 5 Jan 2006, Tom Lane wrote:
>
> The difference between the cached and non-cached states is that the
> kernel has seen fit to remove those pages from its cache. It is
> reasonable to suppose that it did so because there was a more immediate
> use for the memory. Trying to override that behavior will therefore
> result in de-optimizing the global performance of the machine.
>

Yeah, so in another word, warm-up cache is just wasting of time if the
pages are already in OS caches. I agree with this. But does this mean it
may deserve to experiment another strategy: big-stomach Postgres, i.e.,
with big shared_buffer value. By this strategy, (1) almost all the buffers
are in our control, and we will know when a pre-read is needed; (2) avoid
double-buffering: though people are suggested not to use very big
shared_buffer value, but in practice, I see people gain performance by
increase it to 200000 or more.

Feasibility: Our bufmgr lock rewrite already makes this possible. But to
enable it, we may need more work: (w1) make bufferpool relation-wise,
which makes our estimation of data page residence more easy and reliable.
(w2) add aggresive pre-read on buffer pool level. Also, another benefit of
w1 will make our query planner can estimate query cost more precisely.

Regards,
Qingqing

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Drake 2006-01-06 02:09:45 Re: catalog corruption bug
Previous Message Tom Lane 2006-01-06 01:17:23 Re: Warm-up cache may have its virtue