On Thu, Dec 1, 2011 at 4:09 AM, Andres Freund <and...@anarazel.de> wrote: >> Oh, that's interesting. Why do you want to avoid frequent fsyncs? I >> thought the point of synchronous_commit=off was to move the fsyncs to >> the background, but not necessarily to decrease the frequency. > Is that so? If it wouldn't avoid fsyncs how could you reach multiple thousand > TPS in a writing pgbench run on a pretty ordinary system with fsync=on?
Eh, well, what would stop you from achieving that? An fsync operation that occurs in the background doesn't block further transactions from completing. Meanwhile, getting the WAL records on disk faster allows us to set hint bits sooner, which is a significant win, as shown by the numbers I posted upthread. One possible downside of trying to kick off the fsync more quickly is that if there are a continuous stream of background fsyncs going on, a process that needs to do an XLogFlush in the foreground (i.e. a synchronous_commit=on transaction in the middle of many synchronous_commit=off transactions) might be more likely to find an fsync already in progress and therefore need to wait until it completes before starting the next one, slowing things down. But I'm a bit reluctant to believe that is a real effect without some data. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers