Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...
Date: 2014-10-13 14:49:44
Message-ID: sig.0363a724bd.098A57F3-AE53-4597-AA69-34C3AC5E356A@chittenden.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 correct use of flags to mmap(2) (i.e. prevent mmap(2) pages from hooking in to the syncer). In the same breath, it would also 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(at)chittenden(dot)org

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2014-10-13 14:54:02 Re: JsonbValue to Jsonb conversion
Previous Message Robert Haas 2014-10-13 14:46:45 Re: UPSERT wiki page, and SQL MERGE syntax