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" <and...@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 >
