Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
summaryrefslogtreecommitdiff
path: root/doc/src/FAQ
diff options
context:
space:
mode:
authorBruce Momjian2007-06-02 11:28:01 +0000
committerBruce Momjian2007-06-02 11:28:01 +0000
commit4e023373d0dc5d38b058c1a208188131cd9af902 (patch)
treee1d8f55e948d178fcd43e451eaadb153f0e9d8a7 /doc/src/FAQ
parentededa6dfc8f06c8fb3447513dc18b2d07b8a2c62 (diff)
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
Diffstat (limited to 'doc/src/FAQ')
-rw-r--r--doc/src/FAQ/TODO.html11
1 files changed, 9 insertions, 2 deletions
diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
index a1d458e21b2..90dd0171e0a 100644
--- 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 @@ first. There is also a developer's wiki at<br/>
<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