Re: Warm-up cache may have its virtue
От | Qingqing Zhou |
---|---|
Тема | Re: Warm-up cache may have its virtue |
Дата | |
Msg-id | Pine.LNX.4.58.0601052026420.13793@eon.cs обсуждение исходный текст |
Ответ на | Re: Warm-up cache may have its virtue (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Warm-up cache may have its virtue
|
Список | 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
В списке pgsql-hackers по дате отправления: