Horton

Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Andrew Dunstan <andrew@dunslane.net>

View thread
From: Andrew Dunstan <andrew@dunslane.net>
To: Magnus Hagander <magnus@hagander.net>
Cc: Andres Freund <andres@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Palle Girgensohn <girgen@freebsd.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, Francois Tigeot <ftigeot@wolfpond.org>
Date: 2014-04-21T15:45:49Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add shared_memory_type GUC.

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.

cheers

andrew