Re: shared_buffers documentation
От | Robert Haas |
---|---|
Тема | Re: shared_buffers documentation |
Дата | |
Msg-id | p2h603c8f071004191828z3a096d1etc512deb000d32921@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: shared_buffers documentation (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
On Mon, Apr 19, 2010 at 9:23 PM, Bruce Momjian <bruce@momjian.us> wrote: > Robert Haas wrote: >> > Well, the point is that you are getting it for _unusual_ circumstances. >> > Seems it is only when you are getting it for typical workloads that it >> > should be increased. >> >> I guess. I am not sure we should consider "doing a large CTAS" to be >> an unusual workload, though. Sure, most of us don't do that every >> day, but what do we get out of having it be slow when we do decide to >> do it? Up until today, I had never heard anyone say that there was >> any possible performance trade-off, and... >> >> > However, this is the first time I am hearing that >> > battery-backed cache favors the default value. >> >> ...if that's as bad as it gets, I'm still not sure we shouldn't >> increase the default. Most people will not have their first >> experience of PG on a server with a battery-backed RAID controller, >> I'm thinking. And people who do have battery-backed RAID controllers >> can tune the value down if need be. I have never yet heard anyone >> justify why all the values in postgresql.conf should be defined as >> "the lowest value that works best for at least 1 user". >> >> Then again, I don't really know what I'm talking about. I think we >> should be listening very carefully to people who have spent a lot of >> time tuning this and taking their advice on how it should be set by >> default. > > The current default was just chosen to reduce the PG disk footprint. It > probably should be increased, unless we find that the smaller working > set is a win in many cases. Yeah. 48MB is not much these days. ...Robert
В списке pgsql-hackers по дате отправления: