Re-add TODO and clarify it is for the kernel cache:

< * Allow free-behind capability for large sequential scans, perhaps using
<   posix_fadvise()
> * Allow free-behind capability for large sequential scans to avoid
>   kernel cache spoiling

diff --git a/doc/TODO b/doc/TODO
index 2fdce435dadf322739cd4bb4a03fd31bbc821484..4a5b9b8eca65f764011c6d3ac302e94d9554bf11 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 22:46:01 EDT 2007
+Last updated:      Sat Jun  2 07:27:46 EDT 2007
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -1090,6 +1090,14 @@ Fsync
 Cache Usage
 ===========
 
+* Allow free-behind capability for large sequential scans to avoid
+  kernel cache spoiling
+
+  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

diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
index a1d458e21b2a5279d3bb95bb7e5b5d08b4cb63c4..90dd0171e0a08d2932e43730011b0128e8c006ed 100644 (file)
--- a/doc/src/FAQ/TODO.html
+++ b/doc/src/FAQ/TODO.html
@@ -8,7 +8,7 @@
 
 PostgreSQL TODO List
 Current maintainer:     Bruce Momjian ([email protected])
-Last updated:           Fri Jun  1 22:46:01 EDT 2007
+Last updated:           Sat Jun  2 07:27:46 EDT 2007
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -971,7 +971,14 @@ first.  There is also a developer's wiki at
 Cache Usage
 
 
-  Speed up COUNT(*)
+  Allow free-behind capability for large sequential scans to avoid
+  kernel cache spoiling
+  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
   visibility rules, or a single cached value could be used and
   invalidated if anyone modifies the table.  Another idea is to