4 ms·

I posted this here in hopes to start a discussion on what, if any, follow ups one might like to see to this article. It is rather topical, and even as such was

• nkurz 12y ago
  More specific discussion of "These sophisticated schemes work well for 1 GB of data but not so well for 1 TB of data" would be nice. Instinctively, multiple indexes be more useful on large datasets than on small. What works better on the bigger datasets? I also felt uneasy in the piece about the transitions back and forth from "latency" to "throughput" without discussion of "concurrency". For example, "At present, a 7200-RPM disk has a seek time of about four milliseconds. That means it can find and read new locations on disk about 250 times a second. If a server application relies on finding something on disk at every request, it will be capped at 250 requests per second per disk" assumes a queue depth of 1, whereas "Assuming that writing a record of data takes five milliseconds, and you have to write 20 different records to disk, performing these operations in the page cache and then flushing to disk would cost only a single disk access, rather than 20" assumes that the writes can all be issued in parallel. Perhaps a discussion of Little's Law and how it applies to database architecture?