Re: Perf Benchmarking and regression.
От | Noah Misch |
---|---|
Тема | Re: Perf Benchmarking and regression. |
Дата | |
Msg-id | 20160604004133.GC651375@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Perf Benchmarking and regression. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Perf Benchmarking and regression.
|
Список | pgsql-hackers |
On Fri, Jun 03, 2016 at 03:17:06PM -0400, Robert Haas wrote: > On Fri, Jun 3, 2016 at 2:20 PM, Andres Freund <andres@anarazel.de> wrote: > >> > I'm inclined to give up and disable backend_flush_after (not the rest), > >> > because it's new and by far the "riskiest". But I do think it's a > >> > disservice for the majority of our users. > >> > >> I think that's the right course of action. I wasn't arguing for > >> disabling either of the other two. > > > > Noah was... > > I know, but I'm not Noah. :-) > > We have no evidence of the other settings causing any problems yet, so > I see no reason to second-guess the decision to leave them on by > default at this stage. Other people may disagree with that analysis, > and that's fine, but my analysis is that the case for > disable-by-default has been made for backend_flush_after but not the > others. I also agree that backend_flush_after is much more dangerous > on theoretical grounds; the checkpointer is in a good position to sort > the requests to achieve locality, but backends are not. Disabling just backend_flush_after by default works for me, so let's do that. Though I would not elect, on behalf of PostgreSQL, the risk of enabling {bgwriter,checkpoint,wal_writer}_flush_after by default, a reasonable person may choose to do so. I doubt the community could acquire the data necessary to ascertain which choice has more utility.
В списке pgsql-hackers по дате отправления: