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

From Mark Kirkwood
Subject Re: Fixed xloginsert_locks for 9.4
Date
Msg-id 542F2A94.4020701@catalyst.net.nz
Whole thread Raw
In response to Re: Fixed xloginsert_locks for 9.4  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Fixed xloginsert_locks for 9.4
List pgsql-hackers
On 04/10/14 11:21, Andres Freund wrote:
> On 2014-10-03 18:16:28 -0400, Bruce Momjian wrote:
>> On Sat, Oct  4, 2014 at 12:13:00AM +0200, Andres Freund wrote:
>>>> Do we really want to expose a setting a few of us _might_ ask customers
>>>> to change?
>>>
>>> They also will try that themselves. Our customers aren't a horde of dumb
>>> people. Some of them are willing to try things if they hit scalability
>>> problesm. And *lots* of people hit scalability problems with
>>> postgres. In fact I've seen big users migrate away from postgres because
>>> of them.
>>>
>>> And it's not like this only affects absurd cases. Even a parallel
>>> restore will benefit.
>>
>> I disagree.  I just don't see the value in having such undefined
>> variables.
>
> "undefined variables"? I'm not arguing that we don't need documentation
> for it. Obviously we'd need that. I'm arguing against taking away
> significant scalability possibilities from our users. My bet is that
> it's more than 50% on a bigger machine.
>
> I don't think we can offer absolutely accurate tuning advice, but I'm
> sure we can give some guidance. Let me try.
>

+1

I think it is ok to document our reason for providing the new GUC - 
along with that fact that it is a new one and we need more field testing 
and benchmarks to provide comprehensive advice about how to set - and 
recommend leaving it alone unless consult with experts/this list etc.

Regards

Mark




pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: UPSERT wiki page, and SQL MERGE syntax
Next
From: Bruce Momjian
Date:
Subject: Re: Fixed xloginsert_locks for 9.4