Re: Allow a per-tablespace effective_io_concurrency setting
От | Andres Freund |
---|---|
Тема | Re: Allow a per-tablespace effective_io_concurrency setting |
Дата | |
Msg-id | 20150902222329.GD8555@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Allow a per-tablespace effective_io_concurrency setting (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Allow a per-tablespace effective_io_concurrency setting
|
Список | 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 по дате отправления: