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