Hmmm...let's think outside the schema for a moment. OP is benchmarking two instances of COUNTs against a relational database, each looking for the total number

Hmmm...let's think outside the schema for a moment. OP is benchmarking two instances of COUNTs against a relational database, each looking for the total number of rows in a 3 day period, right? I'm going to make a guess that this is historical data and that "time" is stamped and never changes again... Why not just pre-answer the question by incrementing a field (based on date) in another table every time you add a record. Then instead of COUNTing millions of records in seconds, you can read 3 records in micro-seconds. I know what you're thinking: this will "slow down" your transaction processing time. That's true, but only by microseconds. I'd rather wait a few microseconds several times per day than 61 seconds when I really needed to know something. Just because a DBMS has lots of capabilities (SQL, indexing, triggers, stored procedures) doesn't necessarily mean that's the best way to deploy something. Sometimes a little thinking and some extra functionality in your app can leapfrog mountains. [Aside: I have implemented this exact solution many times, often reducing historical reporting run times by 95% or more. No one ever noticed any latency at transaction update time.]