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
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 |