Spit items:
authorBruce Momjian
Tue, 18 Mar 2008 23:35:21 +0000 (23:35 +0000)
committerBruce Momjian
Tue, 18 Mar 2008 23:35:21 +0000 (23:35 +0000)
* 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.

doc/TODO
doc/src/FAQ/TODO.html

index 4e2b8ed6d6e917a4697352764f8aeb292d7fac5a..ef9131ce6f923f202b321dc29dfac092829952fc 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -1,7 +1,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:    Bruce Momjian ([email protected])
-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
 
index 4255c6a0b1671933a79b1d49be2642cf360fda3b..6088559bbd9825be72ac575ac4b631099796e424 100644 (file)
@@ -8,7 +8,7 @@
 
 

PostgreSQL TODO List

 

Current maintainer:     Bruce Momjian ([email protected])

-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.
@@ -1415,12 +1415,16 @@ first.  There is also a developer's wiki at
 

 

  http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php

 

-  
  • Experiment with multi-threaded backend better resource 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.
    +  
  • 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.
     

       
  • Consider increasing the minimum allowed number of shared buffers
  •  

      http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php