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 20150902222329.GD8555@awork2.anarazel.de
Whole thread Raw
In response to Re: Allow a per-tablespace effective_io_concurrency setting  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Allow a per-tablespace effective_io_concurrency setting  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On 2015-09-02 14:31:35 -0700, Josh Berkus wrote:
> On 09/02/2015 02:25 PM, Tomas Vondra wrote:
> > 
> > As I explained, spindles have very little to do with it - you need
> > multiple I/O requests per device, to get the benefit. Sure, the DBAs
> > should know how many spindles they have and should be able to determine
> > optimal IO depth. But we actually say this in the docs:
> 
> My experience with performance tuning is that values above 3 have no
> real effect on how queries are executed.

I saw pretty much the opposite - the benefits seldomly were significant
below 30 or so. Even on single disks. Which actually isn't that
surprising - to be actually beneficial (that is, turn an IO into a CPU
bound workload) the prefetched buffer needs to actually have been read
in by the time its needed. In many queries processing a single heap page
takes far shorter than prefetching the data from storage, even if it's
on good SSDs.

Therefore what you actually need is a queue of prefetches for the next
XX buffers so that between starting a prefetch and actually needing the
buffer ienough time has passed that the data is completely read in.  And
the point is that that's the case even for a single rotating disk!

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Improving replay of XLOG_BTREE_VACUUM records
Next
From: Andres Freund
Date:
Subject: Re: Allow a per-tablespace effective_io_concurrency setting