Spit items:

bmomjian · bmomjian · commit 2f2b58d64280 · 2008-03-18T23:35:21.000Z
* Experiment with multi-threaded backend better I/O utilization

  This would allow a single query to make use of multiple I/O channels
  simultaneously.  One idea is to create a background reader that can
  pre-fetch sequential and index scan pages needed by other backends.
  This could be expanded to allow concurrent reads from multiple devices
  in a partitioned table.

* Experiment with multi-threaded backend better CPU utilization

  This would allow several CPUs to be used for a single query, such as
  for sorting or query execution.
diff --git a/doc/TODO b/doc/TODO
@@ -1,7 +1,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:	Bruce Momjian (bruce@momjian.us)
-Last updated:		Tue Mar 18 19:32:48 EDT 2008
+Last updated:		Tue Mar 18 19:35:12 EDT 2008
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -1630,13 +1630,18 @@ Miscellaneous Performance
 
   http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php
 
-* Experiment with multi-threaded backend better resource utilization
+* Experiment with multi-threaded backend better I/O utilization
 
-  This would allow a single query to make use of multiple CPU's or
-  multiple I/O channels simultaneously.  One idea is to create a
-  background reader that can pre-fetch sequential and index scan
-  pages needed by other backends.  This could be expanded to allow
-  concurrent reads from multiple devices in a partitioned table.
+  This would allow a single query to make use of multiple I/O channels
+  simultaneously.  One idea is to create a background reader that can
+  pre-fetch sequential and index scan pages needed by other backends.
+  This could be expanded to allow concurrent reads from multiple devices
+  in a partitioned table.
+
+* Experiment with multi-threaded backend better CPU utilization
+
+  This would allow several CPUs to be used for a single query, such as
+  for sorting or query execution.
 
 * Consider increasing the minimum allowed number of shared buffers
 
diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
@@ -8,7 +8,7 @@
 <body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" alink="#0000FF">
 <h1><a name="section_1">PostgreSQL TODO List</a></h1>
 <p>Current maintainer:     Bruce Momjian (<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>)<br/>
-Last updated:           Tue Mar 18 19:32:48 EDT 2008
+Last updated:           Tue Mar 18 19:35:12 EDT 2008
 </p>
 <p>The most recent version of this document can be viewed at<br/>
 <a href="http://www.postgresql.org/docs/faqs.TODO.html">http://www.postgresql.org/docs/faqs.TODO.html</a>.
@@ -1415,12 +1415,16 @@ <h1><a name="section_21">Miscellaneous Performance</a></h1>
 </p>
 <p>  <a href="http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php">http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php</a>
 </p>
-  </li><li>Experiment with multi-threaded backend better resource utilization
-<p>  This would allow a single query to make use of multiple CPU's or
-  multiple I/O channels simultaneously.  One idea is to create a
-  background reader that can pre-fetch sequential and index scan
-  pages needed by other backends.  This could be expanded to allow
-  concurrent reads from multiple devices in a partitioned table.
+  </li><li>Experiment with multi-threaded backend better I/O utilization
+<p>  This would allow a single query to make use of multiple I/O channels
+  simultaneously.  One idea is to create a background reader that can
+  pre-fetch sequential and index scan pages needed by other backends.
+  This could be expanded to allow concurrent reads from multiple devices
+  in a partitioned table.
+</p>
+  </li><li>Experiment with multi-threaded backend better CPU utilization
+<p>  This would allow several CPUs to be used for a single query, such as
+  for sorting or query execution.
 </p>
   </li><li>Consider increasing the minimum allowed number of shared buffers
 <p>  <a href="http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php">http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php</a>
