> 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
