Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...
От | Andres Freund |
---|---|
Тема | Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD... |
Дата | |
Msg-id | 20141013145516.GM18020@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD... (Sean Chittenden <sean@chittenden.org>) |
Список | pgsql-hackers |
On 2014-10-13 07:49:44 -0700, Sean Chittenden wrote: > >> 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: Unless I'm mistaken the pages will still be written back to disk (and not just swap, the actual backing file) if there's memory pressure, no? > > --- 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 If so, that should be a separate change. But why? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: