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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers