Re: Fixed xloginsert_locks for 9.4
| От | Mark Kirkwood |
|---|---|
| Тема | Re: Fixed xloginsert_locks for 9.4 |
| Дата | |
| Msg-id | 542F2A94.4020701@catalyst.net.nz обсуждение исходный текст |
| Ответ на | Re: Fixed xloginsert_locks for 9.4 (Andres Freund <andres@2ndquadrant.com>) |
| Ответы |
Re: Fixed xloginsert_locks for 9.4
|
| Список | pgsql-hackers |
On 04/10/14 11:21, Andres Freund wrote: > On 2014-10-03 18:16:28 -0400, Bruce Momjian wrote: >> On Sat, Oct 4, 2014 at 12:13:00AM +0200, Andres Freund wrote: >>>> Do we really want to expose a setting a few of us _might_ ask customers >>>> to change? >>> >>> They also will try that themselves. Our customers aren't a horde of dumb >>> people. Some of them are willing to try things if they hit scalability >>> problesm. And *lots* of people hit scalability problems with >>> postgres. In fact I've seen big users migrate away from postgres because >>> of them. >>> >>> And it's not like this only affects absurd cases. Even a parallel >>> restore will benefit. >> >> I disagree. I just don't see the value in having such undefined >> variables. > > "undefined variables"? I'm not arguing that we don't need documentation > for it. Obviously we'd need that. I'm arguing against taking away > significant scalability possibilities from our users. My bet is that > it's more than 50% on a bigger machine. > > I don't think we can offer absolutely accurate tuning advice, but I'm > sure we can give some guidance. Let me try. > +1 I think it is ok to document our reason for providing the new GUC - along with that fact that it is a new one and we need more field testing and benchmarks to provide comprehensive advice about how to set - and recommend leaving it alone unless consult with experts/this list etc. Regards Mark
В списке pgsql-hackers по дате отправления: