From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: DB cache size strategies |
Date: | 2004-02-11 16:09:54 |
Message-ID: | 200402110909.54587.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tuesday February 10 2004 11:17, Tom Lane wrote:
>
> Well, if you go *really* small then you find a lot of CPU time gets
> wasted shuffling data from kernel cache to PG cache. The sweet spot
> for theory (1) seems to be to set shared_buffers in the range of 1000 to
> 10000 buffers. (Time was that that was a serious amount of RAM, but
> not any more...)
In theory (1), any consensus on what criteria one ought to use when deciding
between 1000 and 10000?
In general, would it be true to say that if one does *not* anticipate
contention for kernel disk cache space from non-DB processes (e.g., the
dedicated db server), then you probably want to use theory (1)? If one
*does* anticipate such contention (e.g. the all-on-one-box web-db app),
then you probably want to use theory (2) in order to ensure an adequate
cache?
Ed
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Mascari | 2004-02-11 16:12:43 | Re: pl/pythonu |
Previous Message | C G | 2004-02-11 15:56:06 | pl/pythonu |