Re: Horrible CREATE DATABASE Performance in High Sierra

I wrote:
> Current status is that I've filed a bug report with Apple and am waiting
> to see their response before deciding what to do next. If they fix the
> issue promptly then there's little need for us to do anything.

Not having heard a peep from Apple yet, I decided to do a bit more
experimenting. I found that indeed, issuing fewer and larger mmap/msync
requests helps enormously. If you're willing to go as far as issuing
only one per file, the speed seems on par with non-fsync. But that
requires being able to mmap 1GB-sized files, so it's probably not
something we want to do.

What I did instead was to adjust the logic in copy_file() so that the
unit of flush requests can be a multiple of the unit of read/write
requests. (My original thought of just raising the buffer size seems
like not as good an idea; it's less cache-friendly for one thing.)

I find that on both Linux and macOS-with-HFS, requesting a flush only
every 1MB seems to be a win compared to flushing every 64KB as we
currently do. Actually it seems that on macOS, every increment of
increase in the flush distance helps, but with HFS you hit diminishing
returns after 1MB or so. With APFS you need a flush distance of 32MB
or more to have credible performance.

Accordingly I propose the attached patch. If anyone's interested in
experimenting on other platforms, we might be able to refine/complicate
the FLUSH_DISTANCE selection further, but I think this is probably good
enough for a first cut.

regards, tom lane