Re: Fixed xloginsert_locks for 9.4

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Fixed xloginsert_locks for 9.4
Дата
Msg-id 20141003164020.GE14522@momjian.us
обсуждение исходный текст
Ответ на Re: Fixed xloginsert_locks for 9.4  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Fixed xloginsert_locks for 9.4
Re: Fixed xloginsert_locks for 9.4
Список 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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: CREATE IF NOT EXISTS INDEX
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Last Commitfest patches waiting review