Re: Fixed xloginsert_locks for 9.4

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Gregory Smith <gregsmithpgsql(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fixed xloginsert_locks for 9.4
Date: 2014-10-03 16:40:21
Message-ID: 20141003164020.GE14522@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2014-10-03 16:57:33 Re: Last Commitfest patches waiting review
Previous Message Fabrízio de Royes Mello 2014-10-03 16:25:55 Re: CREATE IF NOT EXISTS INDEX