Re: [HACKERS] Time to up bgwriter_lru_maxpages?
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Time to up bgwriter_lru_maxpages? |
Дата | |
Msg-id | CA+TgmobapNv+HfaftrvQ1QLV6XCzryY8Fqybxn20tqQa=h58jg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Time to up bgwriter_lru_maxpages? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Time to up bgwriter_lru_maxpages?
|
Список | pgsql-hackers |
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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: