Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD... - Mailing list pgsql-hackers

From Sean Chittenden
Subject Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...
Date
Msg-id sig.0363a724bd.098A57F3-AE53-4597-AA69-34C3AC5E356A@chittenden.org
Whole thread Raw
In response to Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...
Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...
List pgsql-hackers
>> Perhaps, but I still see no reason not to apply it.  It may not help
>> many people, but it won't hurt anything, either.  So why not?
>
> More complicated, less tested code. For no practial benefit, it'll still
> be slower than posix shm if there's any memmory pressure. But if you
> want to apply it, go ahead, I won't cry louder than this email.
>
> I still think the mmap dsm implementation is a bad idea. We shouldn't
> put additional effort into it. If anything we should remove it.

While you're not wrong in that use of mmap(2) here is potentially a bad idea, much of that is mitigated through the
correctuse of flags to mmap(2) (i.e. prevent mmap(2) pages from hooking in to the syncer).  In the same breath, it
wouldalso be nice if the following were committed: 

> --- src/template/freebsd.orig   2014-05-26 23:54:53.854165855 +0300
> +++ src/template/freebsd        2014-05-26 23:55:12.307880900 +0300
> @@ -3,3 +3,4 @@
>  case $host_cpu in
>    alpha*)   CFLAGS="-O";;  # alpha has problems with -O2
>  esac
> +USE_NAMED_POSIX_SEMAPHORES=1


-sc


--
Sean Chittenden
sean@chittenden.org




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: UPSERT wiki page, and SQL MERGE syntax
Next
From: Pavel Stehule
Date:
Subject: Re: JsonbValue to Jsonb conversion