Re: shared_buffers documentation
От | Bruce Momjian |
---|---|
Тема | Re: shared_buffers documentation |
Дата | |
Msg-id | 201004192136.o3JLaa806181@momjian.us обсуждение исходный текст |
Ответ на | Re: shared_buffers documentation (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: shared_buffers documentation
|
Список | pgsql-hackers |
Robert Haas wrote: > On Mon, Apr 19, 2010 at 10:21 AM, Kevin Grittner > <Kevin.Grittner@wicourts.gov> wrote: > > Robert Haas <robertmhaas@gmail.com> wrote: > > > >> 2. Reading the section on checkpoint_segments reminds me, again, > >> that the current value seems extremely conservative on modern > >> hardware. ?It's quite easy to hit this when doing large bulk data > >> loads or even a big ol' CTAS. ?I think we should consider raising > >> this for 9.1. > > > > Perhaps, but be aware the current default benchmarked better > > than a larger setting in bulk loads. > > > > http://archives.postgresql.org/pgsql-hackers/2009-06/msg01382.php > > > > The apparent reason is that when there were fewer of them the WAL > > files were re-used before the RAID controller flushed them from BBU > > cache, causing an overall reduction in disk writes. ?I have little > > doubt that *without* a good BBU cached controller a larger setting > > is better, but it's not universally true that bigger is better on > > this one. > > I don't actually know what's best. I'm just concerned that we have a > default in postgresql.conf and a tuning guide that says "don't do > that". Maybe the tuning guide needs to be more nuanced, or maybe > postgresql.conf needs to be changed, but it makes no sense to have > them saying contradictory things. The good news about checkpoint_segments is that you get a log file warning message if the value should be increased, i.e. you are checkpointing often than 30 seconds. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com
В списке pgsql-hackers по дате отправления: