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:
commit d86d51a95810caebcea587498068ff32fe28293e
Author: Robert Haas <rhaas@postgresql.org>
Date: Tue Jan 5 21:54:00 2010 +0000
Support ALTER TABLESPACE name SET/RESET ( tablespace_options ).
This patch only supports seq_page_cost and random_page_cost as parameters,
but it provides the infrastructure to scalably support many more.
In particular, we may want to add support for effective_io_concurrency,
but I'm leaving that as future work for now.
Thanks to Tom Lane for design help and Alvaro Herrera for the review.
It seems that time has come.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +