Re: shared_buffers > 284263 on OS X
От | AgentM |
---|---|
Тема | Re: shared_buffers > 284263 on OS X |
Дата | |
Msg-id | F6C394FE-1C8E-451F-974B-4E7CFC6403C4@themactionfaction.com обсуждение исходный текст |
Ответ на | Re: shared_buffers > 284263 on OS X (Brian Wipf <brian@clickspace.com>) |
Ответы |
Re: shared_buffers > 284263 on OS X
|
Список | pgsql-performance |
On Nov 27, 2006, at 2:23 , 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. There is a known unfortunate limitation on Darwin for SysV shared memory which, incidentally, does not afflict POSIX or mmap'd shared memory. http://archives.postgresql.org/pgsql-patches/2006-02/msg00176.php
В списке pgsql-performance по дате отправления: