Just to clarify, I'm not talking about random I/O bound loads today, on hard drives, targetted by the fadvise stuff - these aren't CPU bound, and they will be helped by it.
For sequential scans, this situation is different, since the OS has sufficient read-ahead prefetching algorithms of its own for sequential reads, and the CPU work and I/O work ends up happening in parallel due to that. For what it is worth, you can roughly double to triple the iops of an Intel X-25M on pure random reads if you queue up multiple concurrent reads rather than serialize them. But it is not due to spindles, it is due to the latency of the SATA interface and the ability of the controller chip to issue reads to flash devices on different banks concurrently to some extent. On 12/9/08 7:06 PM, "Robert Haas" <[EMAIL PROTECTED]> wrote: > Well, when select count(1) reads pages slower than my disk, its 16x + slower > than my RAM. Until one can demonstrate that the system can even read pages > in RAM faster than what disks will do next year, it doesn't matter much that > RAM is faster. It does matter that RAM is faster for sorts, hashes, and > other operations, but at the current time it does not for the raw pages > themselves, from what I can measure. > > This is in fact, central to my point. Things will be CPU bound, not I/O > bound. It is mentioned that we still have to access things over the bus, > and memory is faster, etc. But Postgres is too CPU bound on page access to > take advantage of the fact that memory is faster (for reading data pages). As I understand it, a big part of the reason for the posix_fadvise patch is that the current system doesn't do a good job leveraging many spindles in the service of a single query. So the problem is not that the CPU overhead is too large in some general sense but that the disk and CPU operations get serialized, leading to an overall loss of performance. On the other hand, there are certainly cases (such as a database which is entirely in RAM, or all the commonly used parts are in RAM) where there really isn't very much I/O, and in those cases of course the CPU cost will dominate. ...Robert
