Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 04/21/2014 11:59 AM, Alfred Perlstein wrote:
> On 4/21/14 8:45 AM, Andrew Dunstan wrote:
>>
>> On 04/21/2014 11:39 AM, Magnus Hagander wrote:
>>> On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund 
>>> <andres@2ndquadrant.com <mailto:andres@2ndquadrant.com>> wrote:
>>>
>>>     On 2014-04-21 10:45:24 -0400, Tom Lane wrote:
>>>     > Andres Freund <andres@2ndquadrant.com
>>>     <mailto:andres@2ndquadrant.com>> writes:
>>>     > > If there are indeed such large regressions on FreeBSD we need
>>>     to treat
>>>     > > them as postgres regressions. It's nicer not to add config
>>>     options for
>>>     > > things that don't need it, but apparently that's not the case
>>>     here.
>>>     >
>>>     > > Imo this means we need to add GUC to control wether anon
>>>     mmap() or sysv
>>>     > > shmem is to be used. In 9.3.
>>>     >
>>>     > I will resist this mightily.  One of the main reasons to switch
>>>     to mmap
>>>     > was so we would no longer have to explain about SysV shm
>>>     configuration.
>>>
>>>     It's still explained in the docs and one of the dynshm 
>>> implementations
>>>     is based on sysv shmem. So I don't see this as a convincing reason.
>>>
>>>     Regressing installed OSs by 15-20% just to save a couple of 
>>> lines of
>>>     docs and code seems rather unconvincing to me.
>>>
>>>
>>> There's also the fact that even if it's changed in FreeBSD, that 
>>> might be somethign that takes years to trickle out to whatever 
>>> stable release people are actually using.
>>>
>>> But do we really want a *guc* for it though? Isn't it enough (and in 
>>> fact better) with a configure switch to pick the implementation when 
>>> multiple are available, that could then be set by default for 
>>> example by the freebsd ports build? That's a lot less "overhead" to 
>>> keep dragging around...
>>>
>>>
>>
>> That seems to make more sense. I can't imagine why this would be a 
>> runtime parameter as opposed to build time.
>
> I am unsure of the true overhead of making this a runtime tunable so 
> pardon if I'm asking for "a lot".  From the perspective of both an OS 
> developer and postgresql user (I am both) it really makes more sense 
> to have it a runtime tunable for the following reasons:
>
> From an OS developer making this a runtime allows us to much more 
> easily do the testing (instead of needing two compiled versions).
> From a sysadmin perspective it makes switching to/from a LOT easier in 
> case the new mmap code exposes a stability or performance bug.
>
>

1. OS developers are not the target audience for GUCs. If the OS 
developers want to test and can't be botherrd with building with a 
couple of different parameters then I'm not very impressed.

2. We should be trying to get rid of GUCs where possible, and only add 
them when we must. The more there are the more we confuse users. If a 
packager can pick a default surely they can pick build options too.

cheers

andrew