Re: DB cache size strategies
От | Ed L. |
---|---|
Тема | Re: DB cache size strategies |
Дата | |
Msg-id | 200402102301.22176.pgsql@bluepolka.net обсуждение исходный текст |
Ответ на | Re: DB cache size strategies (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: DB cache size strategies
|
Список | pgsql-general |
On Tuesday February 10 2004 10:26, Tom Lane wrote: > > Giving PG half the RAM is counterproductive no matter what --- that > pretty much guarantees that every page that's in RAM will be in RAM > twice, once in PG buffers and once in kernel buffers. The two > reasonable schools of thought are (1) to make PG buffers relatively > small and let the kernel do the bulk of the buffering, or (2) to give > PG most of the RAM and expect it to do the bulk of the buffering. > > Past experience has been that theory (1) generally wins. Jan's recent > work on ARC buffering may make things more interesting, though. So, pursuing theory (1) in 'the time before ARC', assuming you have a dedicated box with little or no non-db competition for resources, why give PG anymore than is absolutely required (max_connections*2 or 16)? Why not just let the kernel reign as completely as possible? Is that what you mean by "relatively small"? TIA.
В списке pgsql-general по дате отправления: