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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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