Hi, On 2017-10-02 18:33:17 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > To demonstrate what I'm observing here, on linux with a fairly fast ssd: > > ... > > I tried to replicate this test as closely as I could on the Mac hardware > I have laying about.
Thanks! > I only bothered with the synchronous_commit=off case, though, since > you say that shows the worst effects. That's the case on linux at least, but I'd suspect it's a much more general thing - you just can't get that much data dirty with pgbench otherwise. > I'm kind of surprised that machine B doesn't show obvious tanking in this > test given that msync() makes it suck so badly at copying a database. > I wonder what is different from the kernel's standpoint ... maybe the > sheer number of different files mmap'd by a single process during the > copy? Yea, that's curious. I've really no clue about OSX, so pardon my question: With HEAD and CREATE DATABASE, is it IO blocked or kernel cpu blocked? > If we could arrange to not use pg_flush_after in copydir.c on macOS, > I'd be okay with leaving it alone for the configurable flush_after > calls. But I can't think of a way to do that that wouldn't be a > complete kluge. I don't much want to do > > +#ifndef __darwin__ > pg_flush_data(dstfd, offset, nbytes); > +#endif > > but I don't see any better alternative ... What we could do is introduce a guc (~create_database_flush_data) that controls whether we flush here, and have the defaults set differently on OSX. Not sure if that's actually any better. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
