Benchmarks are indeed hard, which is why I only posted a very specific couple of numbers. Postgres isn't using an index for the count. When you're essentially

Benchmarks are indeed hard, which is why I only posted a very specific couple of numbers. Postgres isn't using an index for the count. When you're essentially tallying an entire table it's a lot less efficient to traverse a B-Tree than to just sequentially stream the table, which is something Postgres is pretty good at. Here's a sample explain output [1]. Mind you, that server was under heavy load (load avg 12) when I ran the query, which is why the numbers are higher than usual; with no competing CPU or I/O, it normally takes about 500ms. That box has only 4GB of RAM, out of which it's using about 512MB for caching, and the OS is using about 1.5GB for the file page cache. As you can see from the plan, it's hitting 38,108 buffers, or 297MB of data, meaning its plowing through approximately 148MB/sec to compute the aggregation. For comparison, RethinkDB chugs about 6GB of RAM before it manages to eke out some results from that query. I'm honestly not sure what it's doing. [1] https://gist.github.com/atombender/e97dde73ed90054c7626 https://gist.github.com/atombender/e97dde73ed90054c7626