summaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorBruce Momjian2007-12-12 06:59:56 +0000
committerBruce Momjian2007-12-12 06:59:56 +0000
commitc7e8d0f392b021d4b0b79e2e50b43d0805518a28 (patch)
treeaee53647cee6b441a240388f6fe299312ecdea4a /doc/src
parent1565888578b828363e780265ea7c88cc8e768552 (diff)
This item was fixed in a different way, so has been removed:
< < * 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.
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/FAQ/TODO.html11
1 files changed, 2 insertions, 9 deletions
diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
index 8b141ac26df..21b4036277d 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 Dec 7 12:52:05 EST 2007
+Last updated: Wed Dec 12 01:59:39 EST 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>.
@@ -947,14 +947,7 @@ first. There is also a developer's wiki at<br/>
<h1><a name="section_12">Cache Usage</a></h1>
<ul>
- <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(*)
+ <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