On Sat, Dec 6, 2014 at 7:08 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Wed, Nov 5, 2014 at 12:09:16PM -0600, Merlin Moncure wrote:
>> effective_io_concurrency 1: 46.3 sec, ~ 170 mb/sec peak via iostat
>> effective_io_concurrency 2: 49.3 sec, ~ 158 mb/sec peak via iostat
>> effective_io_concurrency 4: 29.1 sec, ~ 291 mb/sec peak via iostat
>> effective_io_concurrency 8: 23.2 sec, ~ 385 mb/sec peak via iostat
>> effective_io_concurrency 16: 22.1 sec, ~ 409 mb/sec peak via iostat
>> effective_io_concurrency 32: 20.7 sec, ~ 447 mb/sec peak via iostat
>> effective_io_concurrency 64: 20.0 sec, ~ 468 mb/sec peak via iostat
>> effective_io_concurrency 128: 19.3 sec, ~ 488 mb/sec peak via iostat
>> effective_io_concurrency 256: 19.2 sec, ~ 494 mb/sec peak via iostat
>>
>> Did not see consistent measurable gains > 256
>> effective_io_concurrency. Interesting that at setting of '2' (the
>> lowest possible setting with the feature actually working) is
>> pessimal.
>
> Very interesting. When we added a per-tablespace random_page_cost,
> there was a suggestion that we might want to add per-tablespace
> effective_io_concurrency someday:
What I'd really like to see is to have effective_io_concurrency work
on other types of scans. It's clearly a barn burner on fast storage
and perhaps the default should be something other than '1'. Spinning
storage is clearly dead and ssd seem to really benefit from the posix
readhead api.
merlin