Re: Allow a per-tablespace effective_io_concurrency setting - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Allow a per-tablespace effective_io_concurrency setting
Date
Msg-id 20150904163725.GB5516@awork2.anarazel.de
Whole thread Raw
In response to Re: Allow a per-tablespace effective_io_concurrency setting  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On 2015-09-04 17:21:38 +0100, Greg Stark wrote:
> Wouldn't SSDs need much *less* aggressive prefetching? There's still
> latency and there are multiple I/O channels so they will still need
> some. But spinning media gives latencies measured in milliseconds. You
> can process a lot of tuples in milliseconds. If you have a hundred
> spindles you want them all busy doing seeks because in the 5ms it
> takes them to do that you can proess all the results on a single cpu
> and the rest of time is spend waiting.
> 
> When your media has latency on the order of microseconds then you only
> need to have a small handful of I/O requests in flight to keep your
> processor busy.

Most(?) SSDs have latencies between 0.1 and 0.4 ms for individual random
reads, often significantly more when a lot of IO is going on. In that
time you can still process a good number of pages on the CPU level.

Sure, there's few workloads where you need dozens of SSDs to parallelize
random reads like in the rotating media days. But that doesn't mean you
don't need prefetching?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Allow a per-tablespace effective_io_concurrency setting
Next
From: Alvaro Herrera
Date:
Subject: Re: BRIN INDEX value