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
