From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Brent Dearth <brent(dot)dearth(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Horrible CREATE DATABASE Performance in High Sierra |
Date: | 2017-10-02 19:49:09 |
Message-ID: | 20171002194909.snmsclughwg4txzd@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-10-02 19:54:43 | Re: Horrible CREATE DATABASE Performance in High Sierra |
Previous Message | Brent Dearth | 2017-10-02 19:47:59 | Re: Horrible CREATE DATABASE Performance in High Sierra |