3 ms·

>Ability to scan and filter 5-10 million rows per second on a single core >Ability to aggregate 1-2 million rows per second on a single core This almost makes

>Ability to scan and filter 5-10 million rows per second on a single core >Ability to aggregate 1-2 million rows per second on a single core This almost makes it sound as if increasing to N cores will increase the ops by N * rows per second. But it won't, not even close, not when you are reading from the same hard drive/SSD card. If you are basing your calculation on max I/O output, then additional CPU cores will make little to no difference or worse would decrease performance.

anarazel 9y ago
> This almost makes it sound as if increasing to N cores will increase the ops by N * rows per second. But it won't, not even close, not when you are reading from the same hard drive/SSD card. If you are basing your calculation on max I/O output, then additional CPU cores will make little to no difference or worse would decrease performance. In practice for plans involving seqscans and such you'll very commonly hit CPU bottlenecks before you hit IO limitations. Especially if you aggregate with a few aggregates. We (the pg community) are working on making that less of a bottleneck, but it's still a common occurrence. The point here is that you have multiple constraints, including IO and CPU, and you can roughly calculate which ones you'll hit first.
danjoc 9y ago
>But it won't, not even close, not when you are reading from the same hard drive/SSD card. I think you missed the part where OP said, "In general, you should aim to have a cache hit ratio of 99% or higher" You sound like you have PTSD from under powered hardware and a badly configured database.