Vitesse Data: Postgres + LLVM

Re:Vitesse Data: Postgres + LLVM by justinsb on Friday October 17, 2014 @11:10AM (#8471330)

It really depends on your workload. If your working-set fits into memory and is read-mostly, your I/O is basically irrelevant. Even if you're not in-memory, if you are doing mostly sequential reads (like the OLAP queries they are benchmarking), each drive can do ~200MB/second, so it is not too difficult to become CPU bound if you are doing any significant processing on each row (particularly if your row size is small!)

For OLTP queries, particularly with working-set > RAM or lots of writes, your disk I/O is probably the bottleneck (probably your IOPS, actually, which is why SSD can be so valuable). Pretty sure they're not targeting that use-case though!

[ Parent | on HN ]

Re:Vitesse Data: Postgres + LLVM by swasheck on Friday October 17, 2014 @12:24PM (#8471718)

in my experience (which isn't the sum-total of all human experience), our OLAP queries have a bottleneck at the fiber interconnect between the storage controller and the OS. cpu still isn't the problem for our OLAP systems.

your point that great strides have been made in storage such that we could be back at cpu as a bottleneck is well taken though.

[ Parent | on HN ]