It will hit the disk before continuing. It just causes server side batching of more operations into fewer flushes and fsyncs, often improving overall throughpu

It will hit the disk before continuing. It just causes server side batching of more operations into fewer flushes and fsyncs, often improving overall throughput in the case that you have several connections concurrently hitting the DB. Note also that if you do want to avoid atomic commit for particular transactions (less important stuff), you can do that by issuing SET LOCAL synchronous_commit TO OFF within the transaction. But that's not what commit_delay does. http://www.postgresql.org/docs/9.1/static/wal-configuration.html http://www.postgresql.org/docs/9.1/static/wal-configuration.... http://www.postgresql.org/docs/9.1/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT http://www.postgresql.org/docs/9.1/static/runtime-config-wal...