"Monish Shah" <mon...@indranetworks.com> writes: >> I'd be interested to see benchmarks on MySQL/PostgreSQL performance >> with compression enabled. my *guess* would be it isn't beneficial >> since they usually do small reads and writes, and there is little >> gain in reading 4 KiB instead of 8 KiB. > > OK, now you have switched from compressibility of data to > performance advantage. As I said above, this kind of data usually > compresses pretty well.
the thread has been about I/O performance since the first response, as far as I can tell. > I agree that for random reads, there wouldn't be any gain from > compression. For random writes, in a copy-on-write file system, > there might be gains, because the blocks may be arranged in > sequential fashion anyway. We are in the process of doing some > performance tests to prove or disprove this. > > Now, if you are using SSDs for this type of workload, I'm pretty > sure that compression will help writes. The reason is that the > flash translation layer in the SSD has to re-arrange the data and > write it page by page. If there is less data to write, there will > be fewer program operations. > > Given that write IOPS rating in an SSD is often much less than read > IOPS, using compression to improve that will surely be of great > value. not necessarily, since a partial SSD write is much more expensive than a full block write (128 KiB?). in a write intensive application, that won't be an issue since the data is flowing steadily, but for the right mix of random reads and writes, this may exacerbate the bottleneck. > At this point, this is educated guesswork. I'm going to see if I > can get my hands on an SSD to prove this. that'd be great! -- Kjetil T. Homme Redpill Linpro AS - Changing the game _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
