Tom Lane wrote: > The tests that started this thread are pretty unconvincing in my eyes, > because they are comparing open_sync against code that fsyncs after each > one-block write. Under those circumstances, *of course* fsync will lose > (or at least do no better), because it's forcing the same number of > writes through a same-or-less-efficient API. The reason that this isn't > a trivial choice is that Postgres doesn't necessarily need to fsync > after every block of WAL. In particular, when doing large transactions > there could be many blocks written between fsyncs, and in that case you > could come out ahead with fsync because the kernel would have more > freedom to schedule disk writes.
My guess is that the majority of queries do not fill more than one WAL block. Sure some do, but in those cases the fsync is probably small compared to the duration of the query. If we had a majority of queries filling more than one block we would be checkpointing like crazy and we don't normally get reports about that. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])