Fuzzy.cz

So let's see the next part of SSD results - read-write pgbench. Just like in case of a read-only benchmark, the performance of all file systems is almost exactly the same (with the exception of nilfs2, as mentioned later). The average performance looks like this

BTW I forgot to mention one important thing in the previous post - if you're interested in the data collected during the benchmark, I'm ready to provide them. There's one slight inconvenience, though - the HDD results occupy 3.4GB (1GB gzipped), SSD results occupy 38GB (10GB compressed). That's too much to place it to this blog. But if you're going to pgconf.eu in Amsterdam, just ask me ...

I've already briefly analyzed results of the read-only pgbench runs, now it's time to discuss the read-write workload. The average tps for all file systems with write barriers enabled looks like this

That clearly shows that, just like in case of a read-only workload, better performance is achieved with smaller database blocks. The difference between 1kB and 32kB blocks is about 30%, depending on the file system block size.

In the previous post, I've briefly described benchmark results, especially how to interpret the images. Now it's time to analyze the first part of the results, namely the read-only portion of the OLTP workload (i.e. the output of the read-only pgbench runs).

TPS over all tested file systems (detailed comparison is available here), with XFS excluded (it's the only system with 512B blocks and makes the image a bit less readable) looks like this

The image clearly shows that the best performance is achieved for small database blocks and large file system blocks. The dependency on file system block size is not equally strong for all the file systems - for some file systems it's quite strong, for other file systems there's almost no dependecy.

A few days ago I went to Pilsen, to talk about database replication (general theory and some details about PostgreSQL replication) at a local JUG meeting. One of the questions you usually get after such talk is what is the overhead of a hot standby. The usual answer is "minimal" but that's not exactly a reliable answer ... so let's see a bit more thorough answer based on a simple benchmark.