Well doesn't that depend on what metric you use to define speed?
It sounds like you are measuring latency... but if you were to measure throughput you may be getting a different answer.
The 100 ms flush may not do much good for latency, but it can allow some good batching on writes, which would most likely increase throughput vs having a write flush at every transaction commit.
And it's actually more complex than this, because it depends on the hardware you have, its cache size and whether you have a BBU with a battery that will last long enough to flush the contents of the cache to "permanent and durable storage" in case of power outage.
In other words: YMMV
back
1 comments
Indeed, choice of metrics matte.r To add to what you're saying, there are even more metrics than that!
Consider latency as an example. There's average latency and nth percentile latency (and a similar metric of % of requests above certain latency). You can plot the latency as a CDF (Cumulative distribution function) to visualize it differently. The amount of time you run the benchmark affects things, as performance is typically better 5 seconds in compared to 5 hours in. Performance consistency within a closely bounded temporal interval matters a lot too, as too spiky performance can be detrimental.
Is the same workload being performed? Are the machines configured similarly, or is one a replica cluster while another one is a slower NAS? Are the indexes similar? What is the read workload during that time, as no reads vs high reads affect write latency rate.
And we're just talking about one metric for a database. There are other related metrics -- like iops, cpu taken, memory taken, disk taken, disk writes, disk amplification (io per op), etc, that all 'matter'.