Update description:

< * Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
> * Allow ORDER BY ... LIMIT # to select high/low value without sort or
868c868
<   Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort
>   Right now, if no index exists, ORDER BY ... LIMIT # requires we sort
870a871
>   MIN/MAX already does this, but not for LIMIT > 1.

diff --git a/doc/TODO b/doc/TODO
index 76213752d34bc16b058c57549dbefd7623f580c3..e43185fb32d2eae212c0e76968ff1717c5ce12fb 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -2,7 +2,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:    Bruce Momjian ([email protected])
-Last updated:      Mon Apr 25 09:03:30 EDT 2005
+Last updated:      Mon Apr 25 11:35:24 EDT 2005
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -862,12 +862,13 @@ Optimizer / Executor
 ====================
 
 * Add missing optimizer selectivities for date, r-tree, etc
-* Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
+* Allow ORDER BY ... LIMIT # to select high/low value without sort or
   index using a sequential scan for highest/lowest values
 
-  Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort 
+  Right now, if no index exists, ORDER BY ... LIMIT # requires we sort
   all values to return the high/low value.  Instead The idea is to do a 
   sequential scan to find the high/low value, thus avoiding the sort.
+  MIN/MAX already does this, but not for LIMIT > 1.
 
 * Precompile SQL functions to avoid overhead
 * Create utility to compute accurate random_page_cost value

diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
index a4b407d153ba8d11d3a8c1f0ea44bd85a0848af3..eba1ec7576a0d69646d3ee0379d41a4a5a852008 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:           Mon Apr 25 09:03:30 EDT 2005
+Last updated:           Mon Apr 25 11:35:24 EDT 2005
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -787,11 +787,12 @@ first.
 
 
   Add missing optimizer selectivities for date, r-tree, etc
-  Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
+  Allow ORDER BY ... LIMIT # to select high/low value without sort or
   index using a sequential scan for highest/lowest values
-  Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort 
+  Right now, if no index exists, ORDER BY ... LIMIT # requires we sort
   all values to return the high/low value.  Instead The idea is to do a 
   sequential scan to find the high/low value, thus avoiding the sort.
+  MIN/MAX already does this, but not for LIMIT > 1.
 
   Precompile SQL functions to avoid overhead
   Create utility to compute accurate random_page_cost value