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 <andres@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