From 4e023373d0dc5d38b058c1a208188131cd9af902 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sat, 2 Jun 2007 11:28:01 +0000 Subject: 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 --- doc/src/FAQ/TODO.html | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'doc/src') 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 @@

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. @@ -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 -- cgit v1.2.3