Re: Fixed xloginsert_locks for 9.4

On Fri, Oct 3, 2014 at 1:40 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Fri, Oct 3, 2014 at 04:11:30PM +0200, Andres Freund wrote:
> > On 2014-10-03 10:07:39 -0400, Gregory Smith wrote:
> > > On 10/3/14, 8:26 AM, Andres Freund wrote:
> > > >#define NUM_XLOGINSERT_LOCKS 1
> > > >tps = 52.711939 (including connections establishing)
> > > >#define NUM_XLOGINSERT_LOCKS 8
> > > >tps = 286.496054 (including connections establishing)
> > > >#define NUM_XLOGINSERT_LOCKS 16
> > > >tps = 346.113313 (including connections establishing)
> > > >#define NUM_XLOGINSERT_LOCKS 24
> > > >tps = 363.242111 (including connections establishing)
> > >
> > > Just to clarify: that 10% number I threw out was meant as a rough
> estimate
> > > for a system with the default configuration, which is all that I
> tested. It
> > > seemed like people would likely need to tune all the usual things like
> > > checkpoint_segments, shared_buffers, etc. as well before seeing much
> better.
> > > You did all that, and sure enough the gain went up; thanks for
> confirming my
> > > guess.
> > >
> > > I still don't think that means this needs a GUC for 9.4. Look at that
> jump
> > > from 1 to 8. The low-hanging fruit here hasn't just been knocked
> off. It's
> > > been blended into a frozen drink, poured into a glass, and had a little
> > > paper umbrella put on top. I think that's enough for 9.4. But, yes,
> let's
> > > see if we can add delivery to the side of the pool in the next version
> too.
> >
> > So 25% performance on a relatively small machine improvements aren't
> > worth a GUC? That are likely to be larger on a bigger machine?
> >
> > I utterly fail to see why that's a service to our users.
>
> 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.
>
> I remember Informix had a setting that had no description except "try
> different values to see if it helps performance" --- we don't want to do
> that.
>
> What if we emit a server message if the setting is too low? That's how
> we handle checkpoint_segments.
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + Everyone has their own god. +
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Not all GUC need to be straight forward to tune.
If the gains are worthy I don't see any reason not to have it.