On Nov 14, 2006, at 1:11 PM, Merlin Moncure wrote:
> On 11/14/06, Jim C. Nasby <jim@nasby.net> wrote:
>> On Tue, Nov 14, 2006 at 09:17:08AM -0500, Merlin Moncure wrote:
>> > On 11/14/06, Cosimo Streppone <cosimo@streppone.it> wrote:
>> > >I must say I lowered "shared_buffers" to 8192, as it was before.
>> > >I tried raising it to 16384, but I can't seem to find a
>> relationship
>> > >between shared_buffers and performance level for this server.
>> >
>> > My findings are pretty much the same here. I don't see any link
>> > between shared buffers and performance. I'm still looking for hard
>> > evidence to rebut this point. Lower shared buffers leaves more
>> > memory for what really matters, which is sorting.
>>
>> It depends on your workload. If you're really sort-heavy, then having
>> memory available for that will be hard to beat. Otherwise, having a
>> large shared_buffers setting can really help cut down on switching
>> back
>> and forth between the kernel and PostgreSQL.
>>
>> BTW, shared_buffers of 16384 is pretty low by today's standards,
>> so that
>> could be why you're not seeing much difference between that and 8192.
>> Try upping it to 1/4 - 1/2 of memory and see if that changes things.
>
> Can you think of a good way to construct a test case that would
> demonstrate the difference? What would be the 'best case' where a
> high shared buffers would be favored over a low setting?
Something that's read-heavy will benefit the most from a large
shared_buffers setting, since it means less trips to the kernel.
Write-heavy apps won't benefit that much because you'll end up double-
buffering written data.
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
