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 seemed to care. - OpenBSD: couldn't run the benchmark; for some reason this operating system is unable to mmap() 32GB of memory on a recent PC 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
