[fdr]

> Additionally, if fsync = on in this test, then you're mixing a file system test with a database test.

Which is reasonable, given that file systems of any reasonable performance level (read: not user-space file systems) still tend to be bundled with one or at most a handful of reasonable kernel implementations. Turning fsync off would highlight some interesting bottlenecks, but I'm not sure if that makes for the most sensible comparison either. Not only is the fsync/checkpointing period of a database's operation important to model in a broad-spectrum benchmark, but some amount of file system coupling is unavoidable. One example is metadata syscalls to the file system, which have been a point of poor concurrency before[0]

I agree the fsync = off benchmark would be interesting, but I don't think it's fair to say that the information of an fsync = on test is a) less valuable/clearly improperly performed b) necessarily indicative of the most important bottlenecks for database workloads. A kernel that takes a huge lock during fsync(), for example, should be penalized for it.

Finally, fsync = off doesn't accomplish the stated goal of "independence" from the file system. And as seen in Robert Haas's post, non-fsync file system calls can be the problem in high concurrency situations.

[0] http://rhaas.blogspot.com/2011/08/linux-and-glibc-scalabilit...