pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andres Freund <andres@anarazel.de>
To: Greg Stark <stark@mit.edu>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Julien Rouhaud <julien.rouhaud@dalibo.com>
Subject: Re: Allow a per-tablespace effective_io_concurrency setting
Date: Fri, 4 Sep 2015 18:37:25 +0200
Message-ID: <20150904163725.GB5516@awork2.anarazel.de> (raw)
In-Reply-To: <CAM-w4HMi0Sq8dAWQciFFGigpj5XB-MqnmBqZuRkzgOwtO_qXDg@mail.gmail.com>
References: <CAHyXU0wgpE2E3B+rmZ959tJT_adPFfPvHNqeA9K9mkJRAT9HXw@mail.gmail.com>
	<20141209204337.GC24488@momjian.us>
	<CAMkU=1w0nXDcwhyQurh+XCdQ2AyeSLBcMGqrNAYsckLbTqq3mw@mail.gmail.com>
	<55AA2469.20306@dalibo.com>
	<55AA27C3.7060009@dalibo.com>
	<20150902135351.GA5286@alap3.anarazel.de>
	<CAM-w4HNFSi9HAvRXrvPhYf7awhzZq1ojOtcbK064VxC5U5t1jA@mail.gmail.com>
	<20150902223812.GE8555@awork2.anarazel.de>
	<CAHyXU0zCXsiOLzF5dkt-Yqm77JYr5x7=933EVyBa6ufuyGqKqw@mail.gmail.com>
	<CAM-w4HMi0Sq8dAWQciFFGigpj5XB-MqnmBqZuRkzgOwtO_qXDg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (23+ messages)  latest in thread

Message-ID: <20150904163725.GB5516@awork2.anarazel.de>
Permalink:  ../20150904163725.GB5516@awork2.anarazel.de/
Also on:    postgresql.org/message-id/20150904163725.GB5516@awork2.anarazel.de

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: andres@anarazel.de, stark@mit.edu, mmoncure@gmail.com, bruce@momjian.us, jeff.janes@gmail.com, pgsql-hackers@postgresql.org, julien.rouhaud@dalibo.com
  Subject: Re: Allow a per-tablespace effective_io_concurrency setting
  In-Reply-To: <20150904163725.GB5516@awork2.anarazel.de>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox