Re: Auto-tuning work_mem and maintenance_work_mem

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Auto-tuning work_mem and maintenance_work_mem
Дата
Msg-id CABUevEzB=-QHrEyHuN3dbNY-fm_NveBT=c3n2EcnCeyPcwinAw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Auto-tuning work_mem and maintenance_work_mem  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Auto-tuning work_mem and maintenance_work_mem  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
<p dir="ltr"><br /> On Oct 11, 2013 10:23 PM, "Josh Berkus" <<a
href="mailto:josh@agliodbs.com">josh@agliodbs.com</a>>wrote:<br /> ><br /> > On 10/11/2013 01:11 PM, Bruce
Momjianwrote:<br /> > > In summary, I think we need to:<br /> > ><br /> > > *  decide on new defaults
forwork_mem and maintenance_work_mem<br /> > > *  add an initdb flag to allow users/packagers to set
shared_bufffers?<br/> > > *  add an autovacuum_work_mem setting?<br /> > > *  change the default for
temp_buffers?<br/> ><br /> > If we're changing defaults, bgwriter_lru_maxpages and vacuum_cost_limit<br /> >
couldalso use a bump; those thresholds were set for servers with < 1GB<br /> > of RAM<br /><p dir="ltr">Uh, those
arethere to limit io and not memory, right? More memory isn't the reason to increase them, more io is. For people
deployingon modern server hardware then yes it's often low, but for all those deploying in virtualized environments
withio performance reminding you of the 1990ies, I'm not so sure it is... <p dir="ltr">/Magnus <br /> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Auto-tuning work_mem and maintenance_work_mem
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: GIN improvements part 1: additional information