If you're hitting the database concurrently with many sessions, you can get much of the same benefit by just adjusting the PostgreSQL commit_delay and commit_siblings paramaters, so the database batches things into fewer flushes and fsyncs for you.
don't you want to know that the statement hit disk before continuing? If you're a web request thing that is, say, submitting an order, don't you want that order to hit disk before the web request continues, retrieving the order#?
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.
And doing the same client-side is often improving overall throughput in the a few connections multiplexed between a large number of requests in the same manner.
