Re: shared_buffers documentation
От | Bruce Momjian |
---|---|
Тема | Re: shared_buffers documentation |
Дата | |
Msg-id | 201004200123.o3K1NHo15825@momjian.us обсуждение исходный текст |
Ответ на | Re: shared_buffers documentation (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: shared_buffers documentation
|
Список | pgsql-hackers |
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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com
В списке pgsql-hackers по дате отправления: