Re: Allow a per-tablespace effective_io_concurrency setting

On Wed, Sep 2, 2015 at 5:38 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> 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

Yeah. And in the case of solid state disks, it's really a much more
simple case of, "synchronously reading from the disk block by block
does not fully utilize the drive because of various introduced
latencies". I find this talk of platters and spindles to be somewhat
baroque; for a 200$ part I have to work pretty hard to max out the
drive when reading and I'm still not completely sure if it's the drive
itself, postgres, cpu, or sata interface bottlenecking me. This will
require a rethink of e_i_o configuration; in the old days there were
physical limitations of the drives that were in the way regardless of
the software stack but we are in a new era, I think. I'm convinced
prefetching works and we're going to want to aggressively prefetch
anything and everything possible. SSD controllers (at least the intel
ones) are very smart.

merlin