Re: Initial 9.2 pgbench write results

Поиск
Список
Период
Сортировка
От Ants Aasma
Тема Re: Initial 9.2 pgbench write results
Дата
Msg-id CA+CSw_t8dFLrXw5f4kgVz-yLsY2y69NtUcWQgry7kh_XDKFFDA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Initial 9.2 pgbench write results  (Greg Smith <greg@2ndQuadrant.com>)
Ответы Re: Initial 9.2 pgbench write results  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
<p><br /> On Feb 27, 2012 10:36 PM, "Greg Smith" <<a href="mailto:greg@2ndquadrant.com">greg@2ndquadrant.com</a>>
wrote:<br/> > One of the reasons I drilled right into this spot is because of fears that running the writer more
oftenwould sprout regressions in TPS.  I can't explain exactly why exactly having backends write their own buffers out
atthe latest possible moment works significantly better in some cases here.  But that fact isn't new to 9.2; it's just
hasa slightly higher potential to get in the way, now that the writing happens during the sync phase.<p>My hypothesis
forthe TPS regression is that it is due to write combining. When the workload is mainly bound by I/O, every little bit
thatcan be saved helps the bottomline. Larger scalefactors don't get the benefit because there is less write combining
goingon overall.<p>Anyway, most people don't run their databases at 100% load. At lesser loads bgwriter should help end
userlatency. Is there a standard benchmark to measure that?<p>--<br /> Ants Aasma 

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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Checkpointer vs pg_stat_bgwriter
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: xlog location arithmetic