[jwatte]

If the SQL is I/O bound, the kdb version cannot be 1000x faster. And if it's not I/O bound, you're not pushing it right. (Nite: compare columnar SQL here.) K can't make your I/O subsystem faster, and the new OS probably doesn't natively support 99.9% of existing high performance hardware.

[icsa]

The SQL was not I/O bound, per se - that is database/implementation-specific. The benchmarks were evaluated on "hot" data with plenty of RAM available (like any good production system).

Some databases don't manage that situation as well as they should. I.e. - they were developed in an era of small RAM & large disk.

> And if it's not I/O bound, you're not pushing it right. That's exactly the point. k is "pushing it right" while the others don't do nearly as well.

> the new OS probably doesn't natively support 99.9% of existing high performance hardware.

At <500 LOC of ANSI C there's not much to port to new hardware, given a decent C compiler.