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

Re: shared_buffers > 284263 on OS X

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Brian Wipf <brian(at)clickspace(dot)com>
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 09:22:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Mon, Nov 27, 2006 at 07:23:47AM +0000, Brian Wipf wrote:
> 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.

Disk or to the kernel cache?
Jim Nasby                                            jim(at)nasby(dot)net
EnterpriseDB      512.569.9461 (cell)

In response to

pgsql-performance by date

Next:From: Michael StoneDate: 2006-11-27 13:20:22
Subject: Re: Postgres server crash
Previous:From: Merlin MoncureDate: 2006-11-27 08:44:28
Subject: Re: Massive delete of rows, how to proceed?

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