edit: Actually, I get this (uncached) in the sqlite3 CLI (the 60-70ms where via sqlitebrowser):
Run Time: real 0.018 user 0.018164 sys 0.000135
Here is the database if you want to play around with it. https://transfer.sh/VkWXe/sqlite.db.gzedit: Actually, I get this (uncached) in the sqlite3 CLI (the 60-70ms where via sqlitebrowser):
Run Time: real 0.018 user 0.018164 sys 0.000135
Here is the database if you want to play around with it. https://transfer.sh/VkWXe/sqlite.db.gzThe GPU really only helps when you need a higher throughput - eg. you're analyzing many billions of rows, or are running a relatively compute-intensive query.
the overhead of indexes at tiny data sizes like this is minimal, so no surprise that sqlite or pg will compare favorably at laptop scale (FWIW, i ran this on a 4-core macbook pro with no GPU (i.e CPU only) and without indexes, mapd runs the query at ~1.5 sec while sqlite takes ~6).
however, the bigger point is about how this experience scales. take a look at this public demo - https://www.mapd.com/demos/ships. it's 11 billion geo data points, and you'll see the same low millisecond response that FridgeSeal is talking about - again, no indexing (to verify, go to dev tools in your browser, turn on SQLLogging(true) in the console and look at the query times reported for the round trip. i'm sure you appreciate that the overhead (both creation and maintenance) of indexing scales with data size, plus sqlite/pg dont (AFAIK) offer anything by way of GPU-rendered charting.
My point was that the submitted post did not make a convincing argument pro MapD when query times are that much slower than a trivial SQLite database.