Re: Fixed xloginsert_locks for 9.4 - Mailing list pgsql-hackers

From Arthur Silva
Subject Re: Fixed xloginsert_locks for 9.4
Date
Msg-id CAO_YK0WLTDGRDUryvsdpftrjkMQSvxuESotCg7KkQb1niyUt2w@mail.gmail.com
Whole thread Raw
In response to Re: Fixed xloginsert_locks for 9.4  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Fixed xloginsert_locks for 9.4
List pgsql-hackers

On Fri, Oct 3, 2014 at 3:10 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Oct  3, 2014 at 02:07:45PM -0400, Bruce Momjian wrote:
> On Fri, Oct  3, 2014 at 03:00:56PM -0300, Arthur Silva wrote:
> >     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.
> >
> > 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.
>
> Every GUC add complexity to the system because people have to understand
> it to know if they should tune it.  No GUC is zero-cost.

Please see my blog post about the cost of adding GUCs:

        http://momjian.us/main/blogs/pgblog/2009.html#January_10_2009

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

That's true Bruce (nice post, it was a good reading).
But how can we ignore 25%+ improvements (from 8 to 24)?
At very least we should delivery some pretty good defaults.

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: replicating DROP commands across servers
Next
From: Alvaro Herrera
Date:
Subject: Re: replicating DROP commands across servers