Re: intel s3500 -- hot stuff

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. +