On 2014-10-03 18:08:56 -0400, Bruce Momjian wrote: > On Fri, Oct 3, 2014 at 11:58:14PM +0200, Andres Freund wrote: > > On 2014-10-03 17:55:19 -0400, Tom Lane wrote: > > > Andres Freund <and...@2ndquadrant.com> writes: > > > > On 2014-10-03 12:40:21 -0400, Bruce Momjian wrote: > > > >> Well, I think the issue is that having a GUC that can't reasonably be > > > >> tuned by 95% of our users is nearly useless. Few users are going to > > > >> run > > > >> benchmarks to see what the optimal value is. > > > > > > > It's possible to convince customers to play with a performance > > > > influencing parameter and see how the results are. Even in > > > > production. > > > > > > I'm a bit dubious that people will be willing to experiment in production > > > with a GUC that requires a database restart to change. > > > > I've convinced customers to restart databases with several different > > shared_buffers settings... So I'm pretty sure it's possible, in *some* > > cases, for xloginsert_slots. > > > > And even if it's just test/pre-production machines - they're not going > > to benchmark settings they can't reasonably set in production. > > 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 don't think so --- create a custom build if you want that. Won't work in the majority of real world cases. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers