On Mon, Apr 21, 2014 at 05:43:46PM +0200, Andres Freund wrote:
>
> On 2014-04-21 17:39:39 +0200, Magnus Hagander wrote:
> > 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...
>
> Well, we don't know at all it's just freebsd that's affected. In fact, I
> would be surprised if there aren't other platforms that regressed due to
> this.
The only platforms affected are the BSDs.
I ran (or tried to run) Pgbench on the four major ones during the last two
years. My experience so far:
- FreeBSD: has trouble scaling; there's some interest to improve things but nobody has done anything about it yet
- NetBSD: crashes under load; this could have been fixed but when I ran the benchmarks in 2012 none of the developers
seemedto care.
- OpenBSD: couldn't run the benchmark; for some reason this operating system is unable to mmap() 32GB of memory on a
recentPC with 128GB of RAM.
- DragonFly: scales better than everything else out there even with mmap()
Given these results I doubt reintroducing SysV shm memory use on PostgreSQL
is worthwile; most platforms where it has a performance impact have much
bigger issues to fix first.
--
Francois Tigeot