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.

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.
238fb034 · Bruce Momjian · 61cf5351 · 238fb034 · 238fb034
隐藏空白更改
内联并排

Showing with 8 addition and 6 deletion

doc/TODO doc/TODO +4 -3

doc/src/FAQ/TODO.html doc/src/FAQ/TODO.html +4 -3

未找到文件。
--- a/doc/TODO
+++ b/doc/TODO
@@ -2,7 +2,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:	Bruce Momjian (pgman@candle.pha.pa.us)
-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

--- 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:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</a>)<br/>
-Last updated:           Mon Apr 25 09:03:30 EDT 2005
+Last updated:           Mon Apr 25 11:35:24 EDT 2005
 </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>.
@@ -787,11 +787,12 @@ first.

 <ul>
  <li>Add missing optimizer selectivities for date, r-tree, etc
-  </li><li>Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
+  </li><li>Allow ORDER BY ... LIMIT # to select high/low value without sort or
  index using a sequential scan for highest/lowest values
-<p>  Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort 
+<p>  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 &gt; 1.
 </p>
  </li><li>Precompile SQL functions to avoid overhead
  </li><li>Create utility to compute accurate random_page_cost value