public inbox for [email protected]
help / color / mirror / Atom feedeffective_io_concurrency and SSDs
2+ messages / 1 participants
[nested] [flat]
* effective_io_concurrency and SSDs
@ 2016-02-19 00:19 Bruce Momjian <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Bruce Momjian @ 2016-02-19 00:19 UTC (permalink / raw)
To: pgsql-docs
I have created the attached doc patch to update effective_io_concurrency
to more accurately cover SSDs.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Attachments:
[text/x-diff] ssd.diff (1.9K, 2-ssd.diff)
download | inline diff:
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
new file mode 100644
index a09ceb2..feb3777
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
*************** include_dir 'conf.d'
*** 1876,1895 ****
</para>
<para>
! 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.
! </para>
!
! <para>
! 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.
</para>
<para>
--- 1876,1891 ----
</para>
<para>
! 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.
! SSDs and other memory-based storage can often process many
! concurrent requests, so the best value might be in the hundreds.
</para>
<para>
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: effective_io_concurrency and SSDs
@ 2016-06-28 20:09 Bruce Momjian <[email protected]>
parent: Bruce Momjian <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Bruce Momjian @ 2016-06-28 20:09 UTC (permalink / raw)
To: pgsql-docs
On Thu, Feb 18, 2016 at 07:19:57PM -0500, Bruce Momjian wrote:
> I have created the attached doc patch to update effective_io_concurrency
> to more accurately cover SSDs.
Patch applied.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2016-06-28 20:09 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-02-19 00:19 effective_io_concurrency and SSDs Bruce Momjian <[email protected]>
2016-06-28 20:09 ` Bruce Momjian <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox