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(at)2ndquadrant(dot)com <mailto:andres(at)2ndquadrant(dot)com>> wrote:
>>>>
>>>> On 2014-04-21 10:45:24 -0400, Tom Lane wrote:
>>>> > Andres Freund <andres(at)2ndquadrant(dot)com
>>>> <mailto:andres(at)2ndquadrant(dot)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