Re: [HACKERS] Time to up bgwriter_lru_maxpages?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Time to up bgwriter_lru_maxpages?
Дата
Msg-id 20170202014111.vf5mgw6sxit5pkwr@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Time to up bgwriter_lru_maxpages?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2017-02-01 20:38:58 -0500, Robert Haas wrote:
> On Wed, Feb 1, 2017 at 8:35 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2017-02-01 20:30:30 -0500, Robert Haas wrote:
> >> On Wed, Feb 1, 2017 at 7:28 PM, Andres Freund <andres@anarazel.de> wrote:
> >> > On 2016-11-28 11:40:53 -0800, Jim Nasby wrote:
> >> >> With current limits, the most bgwriter can do (with 8k pages) is 1000 pages
> >> >> * 100 times/sec = 780MB/s. It's not hard to exceed that with modern
> >> >> hardware. Should we increase the limit on bgwriter_lru_maxpages?
> >> >
> >> > FWIW, I think working on replacing bgwriter (e.g. by working on the
> >> > patch I send with a POC replacement) wholesale is a better approach than
> >> > spending time increasing limits.
> >>
> >> I'm happy to see it replaced, but increasing the limits is about three
> >> orders of magnitude less work than replacing it, so let's not block
> >> this on the theory that the other thing would be better.
> >
> > I seriously doubt you can meaningfully exceed 780MB/s with the current
> > bgwriter. So it's not like the limits are all that relevant right now.
> 
> Sigh.  The patch is harmless and there are 4 or 5 votes in favor of
> it, one of which clearly states that the person involved has hit seen
> it be a problem in real workloads.  Do we really have to argue about
> this?

I don't mind increasing the limit, it's harmless. I just seriously doubt
it actually addresses any sort of problem.



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Time to up bgwriter_lru_maxpages?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] WAL consistency check facility