Re: Starting PostgreSQL 8.0.4 with more memory [FreeBSD
От | Simon Riggs |
---|---|
Тема | Re: Starting PostgreSQL 8.0.4 with more memory [FreeBSD |
Дата | |
Msg-id | 1130777934.8300.1479.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Starting PostgreSQL 8.0.4 with more memory [FreeBSD (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Starting PostgreSQL 8.0.4 with more memory [FreeBSD
|
Список | pgsql-general |
On Mon, 2005-10-31 at 15:44 +0100, Martijn van Oosterhout wrote: > On Mon, Oct 31, 2005 at 01:34:12PM +0000, Simon Riggs wrote: > > > Secondly, you're assuming that PostgreSQLs caching is at least as > > > efficient as the OS caching, which is more of an assertion than > > > anything else. > > > > Do you doubt that? Why would shared_buffers be variable otherwise? > > Because the optimal hasn't been found and is probably different for > each machine. > > There have been tests that demonstrate that you can raise the buffers > to a certain point which is optimal and after that it just doesn't > help [1]. They peg optimal size at 5-10% of memory. Please read the rest of that thread. Those results and their conclusions were refuted in some detail, which lead to a number of optimizations in 8.0 and 8.1, mostly written by Tom. > Also, as Tom pointed out, any memory assigned to shared buffers can't > be used for sorts, temporary tables, plain old disk caching, trigger > queues or anything else that isn't shared between backends. There are > far more useful uses of memory than just buffering disk blocks. Your point was about cache efficiency as an argument for not increasing shared_buffers. Politely, I don't accept that argument. Clearly, there are some other considerations (for which I agree completely) but those don't prevent you increasing shared_buffers, they just place limits on your overall memory budget which could effect shared_buffers of course. Best Regards, Simon Riggs
В списке pgsql-general по дате отправления: