Re: Allow a per-tablespace effective_io_concurrency setting

<p dir="ltr">That doesn't match any of the empirical tests I did at the time. I posted graphs of the throughput for
varyingnumbers of spindles with varying amount of prefetch. In every case more prefetching increases throuput up to N
timesthe single platter throuput where N was the number of spindles.<p dir="ltr">There can be a small speedup from
overlappingCPU with I/O but that's a really small effect. At most that can be a single request and it would be a very
rarelywould the amount of CPU time be even a moderate fraction of the I/O latency. The only case where they're
comparableis when your reading sequentially and then hopefully you wouldn't be using postgres prefetching at all which
isonly really intended to help random I/O.<br /><div class="gmail_quote">On 2 Sep 2015 23:38, "Andres Freund" <<a
href="mailto:andres@anarazel.de">andres@anarazel.de</a>>wrote:<br type="attribution" /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-09-02 19:49:13 +0100,
GregStark wrote:<br /> > I can take the blame for this formula.<br /> ><br /> > It's called the "Coupon
CollectorProblem". If you hit get a random<br /> > coupon from a set of n possible coupons, how many random coupons
would<br/> > you have to collect before you expect to have at least one of each.<br /><br /> My point is that that's
justthe entirely wrong way to model<br /> prefetching. Prefetching can be massively beneficial even if you only<br />
havea single platter! Even if there were no queues on the hardware or<br /> OS level! Concurrency isn't the right way
tolook at prefetching.<br /><br /> You need to prefetch so far ahead that you'll never block on reading<br /> heap
pages- and that's only the case if processing the next N heap<br /> blocks takes longer than the prefetch of the N+1 th
page.That doesn't<br /> mean there continously have to be N+1 prefetches in progress - in fact<br /> that actually
oftenwill only be the case for the first few, after that<br /> you hopefully are bottlnecked on CPU.<br /><br /> If you
additionallytake into account hardware realities where you have<br /> multiple platters, multiple spindles, command
queueingetc, that's even<br /> more true. A single rotation of a single platter with command queuing<br /> can often
readseveral non consecutive blocks if they're on a similar<br /><br /> - Andres<br /></blockquote></div>