Add third idea about pulling data from indexes.

>   A third idea would be for a heap scan to check if all rows are visible
>   and if so set a per-table flag which can be checked by index scans.
>   Any change to the table would have to clear the flag.  To detect
>   changes during the heap scan a counter could be set at the start and
>   checked at the end --- if it is the same, the table has not been
>   modified --- any table change would increment the counter.

diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
index 076431b275c4bb555c3e1f46c605807803d441c5..35ee8b05934a0446f4f6aaf0b391cd49795cc847 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:           Wed Aug 15 11:36:16 EDT 2007
+Last updated:           Wed Aug 15 11:48:07 EDT 2007
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -1010,6 +1010,13 @@ first.  There is also a developer's wiki at
   add someday to determine which heap pages need vacuuming.  Frequently
   accessed bitmaps would have to be stored in shared memory.  One 8k
   page of bitmaps could track 512MB of heap pages.
+
+  A third idea would be for a heap scan to check if all rows are visible
+  and if so set a per-table flag which can be checked by index scans. 
+  Any change to the table would have to clear the flag.  To detect
+  changes during the heap scan a counter could be set at the start and
+  checked at the end --- if it is the same, the table has not been
+  modified --- any table change would increment the counter.
 
   Consider automatic caching of statements at various levels: