Skip site navigation (1) Skip section navigation (2)

Re: shared_buffers > 284263 on OS X

From: Brian Wipf <brian(at)clickspace(dot)com>
To: Jim C(dot) Nasby <jim(at)nasby(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dave Cramer <pg(at)fastcrypt(dot)com>, pgsql-performance(at)postgresql(dot)org, Guido Neitzer <lists(at)event-s(dot)net>
Subject: Re: shared_buffers > 284263 on OS X
Date: 2006-11-27 07:23:47
Message-ID: 6ADBFE12-7A0D-4809-87CD-1F68755A8AD5@clickspace.com (view raw or flat)
Thread:
Lists: pgsql-performance
On 26-Nov-06, at 11:25 PM, Jim C. Nasby wrote:
> On Sat, Nov 18, 2006 at 08:13:26PM -0700, Brian Wipf wrote:
>> It certainly is unfortunate if Guido's right and this is an upper
>> limit for OS X. The performance benefit of having high shared_buffers
>> on our mostly read database is remarkable.
>
> Got any data about that you can share? People have been wondering  
> about
> cases where drastically increasing shared_buffers makes a difference.

Unfortunately, there are more differences than just the  
shared_buffers setting in production right now; it's a completely  
different set up, so the numbers I have to compare against aren't  
particularly useful.

When I get the chance, I will try to post data that shows the benefit  
of having a higher value of shared_buffers for our usage pattern  
(with all other settings being constant -- well, except maybe  
effective_cache_size). Basically, in our current configuration, we  
can cache all of the data we care about 99% of the time in about 3GB  
of shared_buffers. Having shared_buffers set to 512MB as it was  
originally, we were needlessly going to disk all of the time.

Brian Wipf


In response to

Responses

pgsql-performance by date

Next:From: Guido NeitzerDate: 2006-11-27 07:35:27
Subject: Re: shared_buffers > 284263 on OS X
Previous:From: Guido NeitzerDate: 2006-11-27 07:04:59
Subject: Re: shared_buffers > 284263 on OS X

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group