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 [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
