Re: Auto-tuning work_mem and maintenance_work_mem

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Auto-tuning work_mem and maintenance_work_mem
Дата
Msg-id 20140213203409.GD32126@momjian.us
обсуждение исходный текст
Ответ на Re: Auto-tuning work_mem and maintenance_work_mem  (Kevin Grittner <kgrittn@ymail.com>)
Ответы Re: Auto-tuning work_mem and maintenance_work_mem  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Fri, Oct 11, 2013 at 03:39:51PM -0700, Kevin Grittner wrote:
> Josh Berkus <josh@agliodbs.com> wrote:
> > On 10/11/2013 01:11 PM, Bruce Momjian wrote:
> >> In summary, I think we need to:
> >>
> >> *  decide on new defaults for work_mem and maintenance_work_mem
> >> *  add an initdb flag to allow users/packagers to set shared_bufffers?
> >> *  add an autovacuum_work_mem setting?
> >> *  change the default for temp_buffers?
> >
> > If we're changing defaults, bgwriter_lru_maxpages and vacuum_cost_limit
> > could also use a bump; those thresholds were set for servers with < 1GB
> > of RAM.
> 
> +1 on those.
> 
> Also, I have often had to bump cpu_tuple_cost into the 0.03 to 0.05
> range to get a good plan.  In general, this makes the exact
> settings of *_page_cost less fussy, and I have hit situations where
> I was completely unable to get a good plan to emerge without
> bumping cpu_tuple_cost relative to the other cpu costs.  I know that
> it's possible to engineer a workload that shows any particular cost
> adjustment to make things worse, but in real-life production
> environments I have never seen an increase in this range make plan
> choice worse.

So, would anyone like me to create patches for any of these items before
we hit 9.4 beta?  We have added autovacuum_work_mem, and increasing
work_mem and maintenance_work_mem by 4x is a simple operation.  Not sure
about the others.  Or do we just keep this all for 9.5?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: New hook after raw parsing, before analyze
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: truncating pg_multixact/members