Re: Shared Memory: How to use SYSV rather than MMAP ?
От | Thomas Munro |
---|---|
Тема | Re: Shared Memory: How to use SYSV rather than MMAP ? |
Дата | |
Msg-id | CAEepm=1e220fB2jTm1QH3B4PxcRgB6Zq7bU+iXcUo4hWBqJ4Ww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Shared Memory: How to use SYSV rather than MMAP ? (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Thu, Dec 27, 2018 at 7:25 AM Andres Freund <andres@anarazel.de> wrote: > On December 26, 2018 6:48:31 PM GMT+01:00, Robert Haas <robertmhaas@gmail.com> wrote: > >I disagree. I think there is a growing body of evidence that > >b0fc0df9364d2d2d17c0162cf3b8b59f6cb09f67 killed performance on many > >types of non-Linux systems. This is the first report I recall about > >AIX, but there have been previous complaints about some BSD variants. > > Exactly. I think we should have added this a few years ago. I added a commitfest entry for this. The 0001 patch (shared_memory_type GUC, code written by Andres, with a first swing at documentation by me) seems close to committable, but as Tom pointed out, there is a documentation burden here, and I'm planning to go through and make sure that other relevant sections explain the situation clearly. I don't propose to change the default on any platform. It's a shame that it's still advantageous to use clunky sysv facilities on some systems, but so long as that is the case, it's good to be able to reach that; it's also good to have a reasonable default that doesn't require any sysctl changes, so I think this is a good thing to have as a GUC and mmap should be the default. For the 0002 patch (essentially what Tony asked for, except made to respect the huge_pages GUC by me, untested), I hope Tony or another AIX user will be able to help get this into the right shape. The main idea there is that the default setting huge_pages=try should use large pages if the OS is configured to support that, but otherwise fall back to regular pages (just as we do on Linux and Windows). -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: