Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Palle Girgensohn <girgen(at)freebsd(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Francois Tigeot <ftigeot(at)wolfpond(dot)org>
Subject: Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
Date: 2014-04-21 15:39:39
Message-ID: CABUevEx9LvwT5fKD9_DfK4PobCtOUA=zyAnQQVRJxumGAEwnRw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund <andres(at)2ndquadrant(dot)com>wrote:

> On 2014-04-21 10:45:24 -0400, Tom Lane wrote:
> > Andres Freund <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...

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-04-21 15:40:36 Re: Composite Datums containing toasted fields are a bad idea(?)
Previous Message Tom Lane 2014-04-21 15:30:57 Re: Composite Datums containing toasted fields are a bad idea(?)