From 46eafc8855d7c21e2c1a45faa77a3d5a2fc2c8b2 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Tue, 28 Jun 2016 16:09:04 -0400 Subject: [PATCH] doc: update effective_io_concurrency for SSDs SSDs are no longer exotic, so recommend a default in the hundreds for them. --- doc/src/sgml/config.sgml | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index a82bf065a0..061697b54c 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1944,20 +1944,16 @@ include_dir 'conf.d' - A good starting point for this setting is the number of separate + For magnetic drives, a good starting point for this setting is the + number of separate drives comprising a RAID 0 stripe or RAID 1 mirror being used for the database. (For RAID 5 the parity drive should not be counted.) However, if the database is often busy with multiple queries issued in concurrent sessions, lower values may be sufficient to keep the disk array busy. A value higher than needed to keep the disks busy will only result in extra CPU overhead. - - - - For more exotic systems, such as memory-based storage or a RAID array - that is limited by bus bandwidth, the correct value might be the - number of I/O paths available. Some experimentation may be needed - to find the best value. + SSDs and other memory-based storage can often process many + concurrent requests, so the best value might be in the hundreds.