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

bmomjian · bmomjian · commit 4e023373d0dc · 2007-06-02T11:28:01.000Z
&lt; * Allow free-behind capability for large sequential scans, perhaps using
&lt;   posix_fadvise()
&gt; * Allow free-behind capability for large sequential scans to avoid
&gt;   kernel cache spoiling
diff --git a/doc/TODO b/doc/TODO
@@ -1,7 +1,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:	Bruce Momjian (bruce@momjian.us)
-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
@@ -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:           Fri Jun  1 22:46:01 EDT 2007
+Last updated:           Sat Jun  2 07:27:46 EDT 2007
 </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>.
@@ -971,7 +971,14 @@ <h1><a name="section_13">Fsync</a></h1>
 <h1><a name="section_14">Cache Usage</a></h1>
 
 <ul>
-  <li>Speed up COUNT(*)
+  <li>Allow free-behind capability for large sequential scans to avoid
+  kernel cache spoiling
+<p>  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.
+</p>
+  </li><li>Speed up COUNT(*)
 <p>  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
