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
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
