TODO item not needed anymore now that the buffer cache is
authorBruce Momjian
Sat, 2 Jun 2007 02:46:38 +0000 (02:46 +0000)
committerBruce Momjian
Sat, 2 Jun 2007 02:46:38 +0000 (02:46 +0000)
scan-resistant:

<
< * Allow free-behind capability for large sequential scans, perhaps using
<   posix_fadvise()
<
<   Posix_fadvise() can control both sequential/random file caching and
<   free-behind behavior, but it is unclear how the setting affects other
<   backends that also have the file open, and the feature is not supported
<   on all operating systems.

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

index 2fc5bcabc8a9fb24bba8df11e9484f3db7f4d6d7..2fdce435dadf322739cd4bb4a03fd31bbc821484 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -1,7 +1,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:    Bruce Momjian ([email protected])
-Last updated:      Fri Jun  1 14:41:49 EDT 2007
+Last updated:      Fri Jun  1 22:46:01 EDT 2007
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -1090,14 +1090,6 @@ Fsync
 Cache Usage
 ===========
 
-* Allow free-behind capability for large sequential scans, perhaps using
-  posix_fadvise()
-
-  Posix_fadvise() can control both sequential/random file caching and
-  free-behind behavior, but it is unclear how the setting affects other
-  backends that also have the file open, and the feature is not supported
-  on all operating systems.
-
 * Speed up COUNT(*)
 
   We could use a fixed row count and a +/- count to follow MVCC
index c08702392ac210938e719a75eb85b749f8eb16f6..a1d458e21b2a5279d3bb95bb7e5b5d08b4cb63c4 100644 (file)
@@ -8,7 +8,7 @@
 
 

PostgreSQL TODO List

 

Current maintainer:     Bruce Momjian ([email protected])

-Last updated:           Fri Jun  1 14:41:49 EDT 2007
+Last updated:           Fri Jun  1 22:46:01 EDT 2007
 

 

The most recent version of this document can be viewed at

 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -971,14 +971,7 @@ first.  There is also a developer's wiki at
 

Cache Usage

 
 
    -  
  • Allow free-behind capability for large sequential scans, perhaps using
  • -  posix_fadvise()
    -

      Posix_fadvise() can control both sequential/random file caching and

    -  free-behind behavior, but it is unclear how the setting affects other
    -  backends that also have the file open, and the feature is not supported
    -  on all operating systems.
    -

    -  
  • Speed up COUNT(*)
  • +  
  • Speed up COUNT(*)
  •  

      We could use a fixed row count and a +/- count to follow MVCC

       visibility rules, or a single cached value could be used and
       invalidated if anyone modifies the table.  Another idea is to