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

On Sun, Oct 12, 2014 at 5:36 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-10-11 20:33:57 -0400, Bruce Momjian wrote:
>> On Tue, Aug 12, 2014 at 07:08:06PM -0400, Robert Haas wrote:
>> > On Tue, Aug 12, 2014 at 12:59 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> > > On 2014-08-12 09:42:30 -0700, Sean Chittenden wrote:
>> > >> One of the patches that I've been sitting on and am derelict in punting
>> > >> upstream is the attached mmap(2) flags patch for the BSDs. Is there any
>> > >> chance this can be squeezed in to the PostreSQL 9.4 release?
>> > >>
>> > >> The patch is trivial in size and is used to add one flag to mmap(2) calls in
>> > >> dsm_impl.c. Alan Cox (FreeBSD alc, not Linux) and I went back and forth
>> > >> regarding PostgreSQL's use of mmap(2) and determined that the following is
>> > >> correct and will prevent a likely performance regression in PostgreSQL 9.4.
>> > >> In PostgreSQL 9.3, all mmap(2) calls were called with the flags MAP_ANON |
>> > >> MAP_SHARED, whereas in PostgreSQL 9.4 this is not the case.
>> > >
>> > > The performancewise important call to mmap will still use that set of
>> > > flags, no? That's the one backing shared_buffers.
>> > >
>> > > The mmap backend for *dynamic* shared memory (aka dsm) is *NOT* supposed
>> > > to be used on common platforms. Both posix and sysv shared memory will
>> > > be used before falling back to the mmap() backend.
>> >
>> > Hmm, yeah. This might still be a good thing to do (because what do we
>> > lose?) but it shouldn't really be an issue in practice.
>>
>> Is there a reason this was not applied?
>
> IIRC, as pointed out above, it's primarily based on a misunderstanding
> about when mmap is used for in dsm. I.e. that it's essentially just a
> fallback/toy implementation and that posix or sysv should rather be
> used.

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?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company