Re: Fixed xloginsert_locks for 9.4

<div dir="ltr"><div class="gmail_extra"><br /><div class="gmail_quote">On Fri, Oct 3, 2014 at 1:40 PM, Bruce Momjian
<spandir="ltr"><<a href="mailto:bruce@momjian.us" target="_blank">bruce@momjian.us</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
class="HOEnZb"><divclass="h5">On Fri, Oct  3, 2014 at 04:11:30PM +0200, Andres Freund wrote:<br /> > On 2014-10-03
10:07:39-0400, Gregory Smith wrote:<br /> > > On 10/3/14, 8:26 AM, Andres Freund wrote:<br /> > >
>#defineNUM_XLOGINSERT_LOCKS  1<br /> > > >tps = 52.711939 (including connections establishing)<br /> >
>>#define NUM_XLOGINSERT_LOCKS  8<br /> > > >tps = 286.496054 (including connections establishing)<br />
>> >#define NUM_XLOGINSERT_LOCKS  16<br /> > > >tps = 346.113313 (including connections
establishing)<br/> > > >#define NUM_XLOGINSERT_LOCKS  24<br /> > > >tps = 363.242111 (including
connectionsestablishing)<br /> > ><br /> > > Just to clarify:  that 10% number I threw out was meant as a
roughestimate<br /> > > for a system with the default configuration, which is all that I tested.  It<br /> >
>seemed like people would likely need to tune all the usual things like<br /> > > checkpoint_segments,
shared_buffers,etc. as well before seeing much better.<br /> > > You did all that, and sure enough the gain went
up;thanks for confirming my<br /> > > guess.<br /> > ><br /> > > I still don't think that means this
needsa GUC for 9.4.  Look at that jump<br /> > > from 1 to 8.  The low-hanging fruit here hasn't just been
knockedoff.  It's<br /> > > been blended into a frozen drink, poured into a glass, and had a little<br /> >
>paper umbrella put on top.  I think that's enough for 9.4.  But, yes, let's<br /> > > see if we can add
deliveryto the side of the pool in the next version too.<br /> ><br /> > So 25% performance on a relatively small
machineimprovements aren't<br /> > worth a GUC? That are likely to be larger on a bigger machine?<br /> ><br />
>I utterly fail to see why that's a service to our users.<br /><br /></div></div>Well, I think the issue is that
havinga GUC that can't reasonably be<br /> tuned by 95% of our users is nearly useless.  Few users are going to run<br
/>benchmarks to see what the optimal value is.<br /><br /> I remember Informix had a setting that had no description
except"try<br /> different values to see if it helps performance" --- we don't want to do<br /> that.<br /><br /> What
ifwe emit a server message if the setting is too low?  That's how<br /> we handle checkpoint_segments.<br /><span
class="HOEnZb"><fontcolor="#888888"><br /> --<br />   Bruce Momjian  <<a
href="mailto:bruce@momjian.us">bruce@momjian.us</a>>       <a href="http://momjian.us"
target="_blank">http://momjian.us</a><br/>   EnterpriseDB                             <a href="http://enterprisedb.com"
target="_blank">http://enterprisedb.com</a><br/><br />   + Everyone has their own god. +<br /></font></span><div
class="HOEnZb"><divclass="h5"><br /><br /> --<br /> Sent via pgsql-hackers mailing list (<a
href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> To make changes to your
subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers"
target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></div></div></blockquote></div><br
/></div><divclass="gmail_extra">Not all GUC need to be straight forward to tune.<br />If the gains are worthy I don't
seeany reason not to have it.<br /></div></div>