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@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
