On 04/21/2014 11:39 AM, Magnus Hagander wrote:
On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund <and...@2ndquadrant.com
<mailto:and...@2ndquadrant.com>> wrote:
On 2014-04-21 10:45:24 -0400, Tom Lane wrote:
> Andres Freund <and...@2ndquadrant.com
<mailto:and...@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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
