Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD

On 4/21/14 9:24 AM, Andrew Dunstan wrote:
>
> 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.
Thank you for the lecture Andrew!  Really pleasant way to treat a user 
and a fan of the system. :)



-Alfred