3 ms·
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 ca
by jwatte 12y ago
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 12y agoThe 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.