Thanks for this breakdown Tom! FWIW - I'm on Postgres 9.6.5 as bundled with Postgres.app (2.0.5) running on 2013 MBP (2.7GHz i7 / 16GB / SSD) setup. It looks like this might be a priority for an upcoming release, so I might try to hold out for downstream, but thanks for the patch. It will help if we need get custom builds out to fellow devs if this becomes too unbearable.
On Mon, Oct 2, 2017 at 1:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: > > In short, therefore, APFS cannot cope with the way we're using msync(). > > I experimented with this further by seeing whether the msync() code path > is of any value on Sierra either. The answer seems to be "no": cloning > a scale-1000 pgbench database takes about 17-18 seconds on my Sierra > laptop using unmodified HEAD, but if I dike out the msync() logic then > it takes 16-17 seconds. Both numbers jump around a little, but using > msync is strictly worse. > > I propose therefore that an appropriate fix is to unconditionally disable > the msync code path on Darwin, as we have already done for Windows. When > and if Apple changes their kernel so that this path is actually of some > value, we can figure out how to detect whether to use it. > > The msync logic seems to date back to this thread: > > https://www.postgresql.org/message-id/flat/alpine.DEB.2. > 10.1506011320000.28433%40sto > > wherein Andres opined > >> I think this patch primarily needs: > >> * Benchmarking on FreeBSD/OSX to see whether we should enable the > >> mmap()/msync(MS_ASYNC) method by default. Unless somebody does so, I'm > >> inclined to leave it off till then. > > but so far as I can tell from the thread, only testing on FreeBSD ever > got done. So there's no evidence that this was ever beneficial on macOS, > and we now have evidence that it's between counterproductive and > catastrophic depending on which kernel version you look at. > > regards, tom lane >
