> For a 50-entry timeline, the latency is usually less than 25 milliseconds. There are a lot of good ideas which don't scale down to a smaller single-core sys

> For a 50-entry timeline, the latency is usually less than 25 milliseconds. There are a lot of good ideas which don't scale down to a smaller single-core system. For example, there's a CROSS JOIN in that example, which is just fine at the row-counts we might encounter on sqlite. The general low-scale workloads + the in-process operation (the SQL query is a function call, not RPC), means that sqlite can avoid needing the complex query to compress the user intent into a single round-trip. This doesn't apply in general & the article doesn't claim to do so. In the past, I've had production systems which are blocked on mysql_parse() rather than the actual disk IO (anyone remember the mysql Drizzle client side optimizations & the Dynamic SQL extensions?). The simplicity of 1+N is basically a "simple enough and it always works", plus in a few case we can actually use a different projection for the N queries. As a side note to Fossil, I've gone spelunking into the SVN repos with sqlite (there's a .db inside your .svn/ if you still use it) & what you'd end up using is a lot of 1+N queries (ACTUAL_NODE).