That doesn't match any of the empirical tests I did at the time. I posted graphs of the throughput for varying numbers of spindles with varying amount of prefetch. In every case more prefetching increases throuput up to N times the single platter throuput where N was the number of spindles.
There can be a small speedup from overlapping CPU with I/O but that's a really small effect. At most that can be a single request and it would be a very rarely would the amount of CPU time be even a moderate fraction of the I/O latency. The only case where they're comparable is when your reading sequentially and then hopefully you wouldn't be using postgres prefetching at all which is only really intended to help random I/O.
On 2 Sep 2015 23:38, "Andres Freund" <
andres@anarazel.de> wrote:
On 2015-09-02 19:49:13 +0100, Greg Stark wrote:
> I can take the blame for this formula.
>
> It's called the "Coupon Collector Problem". If you hit get a random
> coupon from a set of n possible coupons, how many random coupons would
> you have to collect before you expect to have at least one of each.
My point is that that's just the entirely wrong way to model
prefetching. Prefetching can be massively beneficial even if you only
have a single platter! Even if there were no queues on the hardware or
OS level! Concurrency isn't the right way to look at prefetching.
You need to prefetch so far ahead that you'll never block on reading
heap pages - and that's only the case if processing the next N heap
blocks takes longer than the prefetch of the N+1 th page. That doesn't
mean there continously have to be N+1 prefetches in progress - in fact
that actually often will only be the case for the first few, after that
you hopefully are bottlnecked on CPU.
If you additionally take into account hardware realities where you have
multiple platters, multiple spindles, command queueing etc, that's even
more true. A single rotation of a single platter with command queuing
can often read several non consecutive blocks if they're on a similar
- Andres
