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

From Merlin Moncure
Subject Re: Allow a per-tablespace effective_io_concurrency setting
Date
Msg-id CAHyXU0zCXsiOLzF5dkt-Yqm77JYr5x7=933EVyBa6ufuyGqKqw@mail.gmail.com
Whole thread Raw
In response to Re: Allow a per-tablespace effective_io_concurrency setting  (Andres Freund <andres@anarazel.de>)
Responses Re: Allow a per-tablespace effective_io_concurrency setting  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Wed, Sep 2, 2015 at 5:38 PM, Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: September 2015 Commitfest
Next
From: Kouhei Kaigai
Date:
Subject: Re: Foreign join pushdown vs EvalPlanQual