Re: Horrible CREATE DATABASE Performance in High Sierra
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Brent Dearth <brent.dearth@gmail.com>
Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>
Date: 2017-10-02T19:42:25Z
Lists: pgsql-hackers
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
Commits
-
Increase distance between flush requests during bulk file copies.
- c3723317d08c 10.1 landed
- 643c27e36ff3 11.0 landed
- 13a8924ecf00 9.6.6 landed