4 ms·
Database systems are already optimized for disk i/o that has blazing fast sequential reads and a high penalty for seeking. SSD's put the seeking penalty to zero
by aston 18y ago
Database systems are already optimized for disk i/o that has blazing fast sequential reads and a high penalty for seeking. SSD's put the seeking penalty to zero, but with worse sequential read speed compared to your typical raided disks.
Which is the long way of saying, it's an expensive option that is unlikely (at least right now) to improve database performance that much.
- timtrueman 18y agoGood point, I didn't really think about that. Perhaps somebody could build a new kind of datastore that takes advantage of that?
- neilc 18y agoPlenty of database workloads involve a lot of random I/O (e.g. anything that does an index lookup is typically doing random I/O). In theory, you should be able to tell the query optimizer about the relative costs of random vs. sequential I/O on your hardware, and have it adjust the costing of query plans accordingly (e.g. PG allows this, at any rate -- it might even be possible to infer that automatically, although not easy). Aside from the query workload, WAL is designed under the assumption that sequential writes are much cheaper than random writes, so you could imagine changing that when using SSDs...