Re: [PATCHES] ARC Memory Usage analysis
От | Simon Riggs |
---|---|
Тема | Re: [PATCHES] ARC Memory Usage analysis |
Дата | |
Msg-id | 1098482465.20926.122.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: [PATCHES] ARC Memory Usage analysis (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, 2004-10-22 at 21:45, Tom Lane wrote: > Jan Wieck <JanWieck@Yahoo.com> writes: > > What do you think about my other theory to make C actually 2x effective > > cache size and NOT to keep T1 in shared buffers but to assume T1 lives > > in the OS buffer cache? > > What will you do when initially fetching a page? It's not supposed to > go directly into T2 on first use, but we're going to have some > difficulty accessing a page that's not in shared buffers. I don't think > you can equate the T1/T2 dichotomy to "is in shared buffers or not". > Yes, there are issues there. I want Jan to follow his thoughts through. This is important enough that its worth it - there's only a few even attempting this. > You could maybe have a T3 list of "pages that aren't in shared buffers > anymore but we think are still in OS buffer cache", but what would be > the point? It'd be a sufficiently bad model of reality as to be pretty > much useless for stats gathering, I'd think. > The OS cache is in many ways a wild horse, I agree. Jan is trying to think of ways to harness it, whereas I had mostly ignored it - but its there. Raw disk usage never allowed this opportunity. For high performance systems, we can assume that the OS cache is ours to play with - what will we do with it? We need to use it for some purposes, yet would like to ignore it for others. -- Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: