On 2017-10-02 15:42:25 -0400, Tom Lane 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.
Well, that's only measuring one type of workload. Could you run a normal pgbench with -P1 or so for 2-3 checkpoint cycles and see how big the latency differences are? > 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. I'm inclined to think you're right. This is a surprisingly massive regression for a new OS release - we're not the only database that uses msync... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
